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: [an error occurred while processing this directive]]

あわせて読みたい