BSD

NetBSDでmingw-w64を作っていて、クロスのgccもbinutilsも出来上がったのに、それでコンパイルしたバイナリをWindowsに持っていって実行しようとすると“not a valid WIN32 application”（日本語版だと「有効なWIN32アプリケーションではありません」）などと言われる。

結論から書くと、binutilsのldのldscriptsが正しく作れていなかった。

configureでSHELLとして何故か/bin/shではなく/bin/kshが選ばれるが、このシェルだとgenscripts.sh（から呼ばれているscripttempl/pep.scなど）がエラーになる。

エラーなので止まってくれれば良いのだが、実際にはそのまま進んで、make installすると途中で打ち切られた（実質中身のない）ldscriptsがインストールされてしまう。

出来上がったgcc+binutilsを使ってコンパイルしたときに、一見すると正しいPE32(+) executableに見えるモノが出来てしまうので、なかなか原因がわからなかった。しかし、以前にも、違うパターンとはいえ同じ部分でハマったことがあったのだった。http://est.ceres.ne.jp/2008/07/02/post_241/…すぐに気がつくべきだった。

回避方法としては、binutilsのconfigureを実行する際、CONFIG_SHELL=/bin/sh …/configure …とでもすれば良い。多分。

普通に pkgsrc/lang/openjdk7 動くようになってた。素晴らしい。

$ uname -srm
NetBSD 5.99.24 amd64
$ /usr/pkg/java/openjdk7/bin/java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Environment (build 1.7.0-internal-pkgsrc_2010_01_23_23_14-b00)
OpenJDK 64-Bit Server VM (build 17.0-b05, mixed mode)

手持ちの Java プログラムをいくつか動かしてみたが特に不具合はなし。GUI のあるプログラムは試してないが。

mod_fcgid の socket / shm のファイル作成場所について。
fcgid_conf.c:

#define DEFAULT_SOCKET_PREFIX "logs/fcgidsock"
#define DEFAULT_SHM_PATH "logs/fcgid_shm"

で，

        config->sockname_prefix =
                ap_server_root_relative(p, DEFAULT_SOCKET_PREFIX);
        config->shmname_path = ap_server_root_relative(p, DEFAULT_SHM_PATH);

なので，apacheもpkgsrcデフォルトのままだとすると，おそらく/usr/pkg/logs/以下になる。

で，標準でそんなディレクトリはないので，

[emerg] (2)No such file or directory: mod_fcgid: Can't create share memory for size %zu byte

といったエラーになる。

仕方がないのでhttpd.confなどで明示する。

<IfModule mod_fcgid.c>
  AddHandler fcgid-script .fcgi
  SocketPath /var/run/fcgidsock
  SharememPath /var/run/fcgid_shm
</IfModule>

SocketPathで指定するのはディレクトリで，その下にwww権限（apacheの実行権限）でソケットが作られる。
SharememPathの方はファイル名そのもの。root権限で作ってくれるようだ。

検索すると/tmp以下に置いている例もあるが，別にした方が良いと思う。

いろいろ新しくなったついでにOSのバージョンも上げたら apache が動かなくなった（笑）。

どうも，pthread が非互換らしい。再コンパイルで解決。

…なんだけれど，perl だけ何度再コンパイルしても libpthread.so.0 をリンクした状態になる。（libpthread.so.1 だけリンクしてほしい）

ちゃんと調べていないけれど，どうも既にインストールされている /usr/pkg/lib/perl5/5.10.0/x86_64-netbsd-thread-multi/CORE/libperl.so の参照先に引っ張られている模様。インストールしてある状態で再コンパイルせずに，pkg_deleteした後に再コンパイルしたらうまくいった。

このへんの関係なのかな？

cc  -Wl,-R/usr/pkg/lib --whole-archive -shared  -L/usr/pkg/lib なんたら.o 
 -o ../../../lib/auto/なんたら/なんたら.so -L../../..
 -Wl,-R/usr/pkg/lib/perl5/5.10.0/x86_64-netbsd-thread-multi/CORE
 -Wl,-R../../../lib/CORE -lperl

NetBSDのメーリングリストで，同じBCM5722のDELLのサーバで，bgeにtso4オプションをつけているとその症状になる（tso4を外せば問題ない）と教えていただきました。やってみたら確かに正常動作。
tso4 Enable hardware-assisted TCP/IPv4 segmentation on interfaces that support it.
BCM5721なら問題ないので，BCM5722の「hardware-assist」の部分に不具合があるんですかね。