2003年10月14日(火)

lam on macosx

とりあえず、 XLF/XLC を使って LAM を野良 build。
一見 make は通るんだが、いざ install しようとすると何故かライブラリを作り損ねている罠。
これが libtool を経由していて、誰が阿呆で作り損ねているのかさっぱり判らない。
generate された libtool 自体がンポなんじゃないかいな?

ともかく autoconf ものは、何か問題があった時に追っかけるのが困難でかなわん。そういや configure も env F77=xlf を無視して f77 でオプションチェックやってやがったぞ。幸い f77 は xlf への symlink だったからいいものの、諸般の事情で別の f77 が見つかるようなシステムだったらどうしていたものか

どうも autoconf ものにはいい思い出がなくて、作者と同じ環境以外では build させないためのツールじゃなかろうかと思ってしまう。

ちなみに、 FreeBSD 環境では PGI Fortran のパフォーマンスを捨てがたかったので Linux の方で LAM を build しようとしたら、ずいぶん昔に買ったものと見えて C++ が微妙に転けまくる。 std::hoge で no instance of overloaded function とか言われると萎えるぞ。

結局もう一つソースツリーを展開して gcc を見つけさせて configure; make して、問題の部分のログを diff したり、ソースツリー自体の diff を取ったり。
やっぱり cc の挙動の違いから必要なコードの足りない libtool が generate されてるようだ。
やはり cc は gcc 以外あり得んか

うーむ、よそで build して持ってくると target の path なんかがバイナリに埋まってるぞな。持ってくる先の環境に合わせて、むこうで build しとかんと駄目かいな?

env F77= してたが、よくみると FC というの別にある罠。

[referer:

Script Error

The script did not produce proper HTTP headers. Please see the error log to see the detail of the errors. Depending on the server configuration, you can also run thisscript under CGIWrap debugging. Usually, either rename or linkthe script temporarily to a file which ends with .cgidextension, or add a AddHandler cgi-script-debug .cgiline to your .htaccess file.

]

あわせて読みたい