福原です． xmhdy897@xxxxxxxxxxx wrote: >>ATLAS と CLAPACK >>をどういう風にインストールしたのでしょうか． > > いずれもソースコードからコンパイルしています。 > clapack は netlib からとってきた version 3.0、 > atlas も本家からの最新版です。 > コンパイルの順番も、指示どおり clapack、atlas の > 順です。 BLAS が先にあった方がいいのかと思って，私は ATLAS を先に していました．もっともざっと見た感じでは，コンパイルの順番は 関係ないような気がします． > clapack は Readme.install にしたがって > コンパイルすると、(4) の blas testing で > 変なエラーメッセージは出ますが、これはどうしようもないの > で無視してます。 # 私は test は飛ばしました． > 普通に atlas をコンパイルしただけだと、 > atlas のディレクトリにできる liblapack.a の中には > zgeev は入っていません。 > 何もしないと、zgeev は、clapack ディレクトリ側の > liblapack.a に入っているだけです。 何もしないと，clapack ディレクトリには liblapack.a は 出来ず，lapack_LINUX.a が出来ると思いますが． シンボリックリンクなりコピーなりしたのなら，そう書いていただかないと わかりません． > atlas/doc/Libreadme.txt の最後の部分に > clapack ディレクトリにできる liblapack.a とマージして > full package を作る方法がかかれています。 私はこれに気付いていませんでした． > これに従って、atlas にできる > liblapack.a と clapack にできる liblapack.a を > マージしています。マージされた liblapack.a は > atlas ディレクトリ側に入ります。 > nm -g 云々でみたのは、マージされた > atlas ディレクトリにある liblapack.a です。 > マージしたので、zgeev が入っています。 > > (念のためですが)なぜこんなことまでやったかと > 言うと、当初はマージしていなかったのですが、 > あんまりリンカが通らないので、atlas ディレクトリ側の > liblapack.a を読んでしまってエラーがでているのか > とも考えられたので、いろいろ調べてみて、 > こういうマージされた liblapack.a を使う方法を > 試したのです。で、結果はやっぱりリンカのエラーは > 変わらないということです。 「とも」というか，-L で複数指定した時は左から見ていくはずなので， atlas ディレクトリ側の liblapack.a を見ているのは当然でしょう． # info gcc の Options for Directory Search を見ると， # -I は複数指定すると左から順にと明記してありますが， # -L は明記してないですね． 私の所でマージしてみたら，-llapack で zgeev も使えるようになりました． -Wl,--verbose -Wl,-v を付けた時の結果を見ると (略) attempt to open ../../../ATLAS/lib/Linux_P4ESSE3/liblapack.so failed attempt to open ../../../ATLAS/lib/Linux_P4ESSE3/liblapack.a succeeded (../../../ATLAS/lib/Linux_P4ESSE3/liblapack.a)ieeeck.o (略) (../../../ATLAS/lib/Linux_P4ESSE3/liblapack.a)zgeev.o (略) となっていました．ファイルサイズは次のようになってます．少しぐらいは 環境によって違うかもしれませんが，あまりに違うのであれば，作り方の問題 かもしれません． 7972620 ATLAS/lib/Linux_P4ESSE3/liblapack.a (マージ後) 310316 ATLAS/lib/Linux_P4ESSE3/liblapack.a-old (マージ前) 7770904 CLAPACK/lapack_LINUX.a # もっとも # >> attempt to open /usr/local/lib/atlas/Linux_PIIISSE1/liblapack.a succeeded # となっていて， # >> Linux_PIIISSE1 ディレクトリ以下の liblapack.a のシンボル # >> リストを確認する # >> と、zgeev_ はちゃんと存在してます。 # というのは，結構不思議なのですが． 以下余談になります． >>-llapack のかわりに lapack_LINUX.a >>を(フルパスで)指定して， > > > 趣旨は、多分、clapack ディレクトリにある > liblapack.a のシンボリックリンク元をフルパスで > 直接参照せよということだと思いますが、 > これって、gcc の -l オプションを使ってできるのですか? > もし直接参照できるなら、やりかたを教えてもらえませんか? -l ではありません． gcc (略) -llapack (略) ではなく gcc (略) /usr/local/lib/clapack/lapack_LINUX.a (略) とするということです．シンボリックリンクがあるのなら gcc (略) /usr/local/lib/clapack/liblapack.a (略) でも同じでしょう． ATLAS/doc/LibReadme.txt によれば，この方法では最適性能は出ないようですね． >>-lF77 の次に -lI77 を追加でどうでしょう． > > > これもうまく行きませんでした。 > > liblapack.a の zgeev.o の中のシンボルをチェックした > 限りの話ですが、zgeev.o は、libI77.a の中の関数を > コールしていないので追加してもかわらないのだと > 思います。 こちらは >>libF77.a でシンボル未解決のエラーが出てますが このエラーに対する対処のつもりでした．言葉足らずですみません． -- 福原 <makoto@xxxxxxxxxxxxxxxxxx>