2004年8月30日の日記の2番目の記事へのコメント
■readlineが5に上がったら
何か知らぬ間にreadline-5.0なんかがリリースされてたんでビルドしてみたんですが,見るとlibreadline.so.5が入るようで,当然今までのlibreadline.so.4は入らず,入れ替えたら案の定readlineを見ていた方々はserioware標準の/usr/lib/libreadline.so.4を見にいくようになっちゃいました.調べてみたら,libreadline.so.4とリンクしているのはbc,Palm関係(pilot-linkとか),xine-ui,それからpythonとrubyのプラグインといったあたりで,大した数ないことが判明.じゃあ,ということで入れ直してみたわけですが・・・.
殆んどのツールはビルドしなおしたらちゃんと/usr/local/lib/libreadline.so.5にリンクしてくれました.ただ,唯一,kdepimのkpilot関連のモジュールが,いくらやっても/usr/lib/libreadline.so.4にリンクしちゃいます.objdumpでRPATH見ると/usr/local/libが先頭にあるんで,RPATHの問題ではなさそう.じわじわと追って行くと,どうやらlibtoolからg++が呼ばれる際に,オプションで -L/usr/local/lib より前に -L/usr/lib/gcc-lib/i586-pc-linux-gnu/3.3.2/../../..が指定されてしまっているのが悪いようです.ていうか,/usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.4 があって,こっちのgccにパスが通ってるのに何で/usr/libの下の方も見にいっちゃってんの???
grepしまくって調べたら,どうやらkde関係はkdepimに限らず皆さん laファイルのdependency_libsに /usr/local/libのi686の方と/usr/libのi586の方の両方が書かれているようで,これがそもそもおかしいっぽい.で,最初に入るartsを使ってさらに調べてみたところ,どうも付属のlibtoolの中で,libstdc++をカレントディレクトリ→/lib→/usr/lib→/usr/local/libの順で探している模様.で,/usr/libで最初にみつかるからi586の方も検出しちゃうように見えます.
これを回避するには,configureした後,libtoolを直接いじって「newlib_search_path=/usr/local/lib」とかしてやれば,最初に/usr/local/libの下を探すようになるのでうまくいくんですが,これ,美しくありませんね.いいやり方,ないのかなぁ.libtoolさっぱりです・・・.
[コメントを書く]
2004年8月30日の日記の2番目の記事へのコメント
[コメントを書く]