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番目の記事へのコメント

中の人情報

名前:
nosuke (のすけ)
メール:
sasugaanijaのgmail.com
「の」は「@」みたいな
関連リンク:

カレンダー

2004年8月
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

<<先月分

翌月分>>

最新の10件のエントリ

最近の10件のコメント

過去ログ