[plamo:06851] Re: Don't exist /usr/lib/libpthread.so

[Seiji Fukagawa]

深川です。

From: KOJIMA Mitsuhiro <kojima@linet.gr.jp>
Date: Sun, 13 Aug 2000 23:48:06 +0900
Message-ID: <20000813234737L.kojima@linet.gr.jp>
> > # -lgthread を外すとまたちょっと動作が違い、ここもちょい謎なのですが。
> > # そもそも -lgthread って？？ pthread との関係は？
> 
> 私も詳しくないですが、libgthread というのは、glib が利用している 
> thread library みたいですね。

  ざっとソースを見たところ、pthread とか SUN thread (何と呼ぶのが正解？)
の違いを吸収するラッパーライブラリみたいですね。
# 使い方がよく分かりませんが。(^^;

> 以前から気にはなっていたんですが、gtk や glib あたりのライブラリはデフォ
> ルト通りの /usr/local/lib 以下にインストールすると他の configure スク
> リプトからも問題なく見つかるのですが、--prefix=/usr として /usr/lib 以
> 下にインストールした場合は、しばしば gtk のチェックに引っかかって 
> configure が正常終了しないことがありました。
> 
> # --disable-gtk-check とかして胡麻化してコンパイルすれば動くんだけど
> 
> もしかしたら、これもライブラリをリンクする順番とかが関わっているのかな？

  それは具体的に何のコンパイルだったかわかります？
configure の処理をもう少し詳しく追えば、どこで引っかかっているか
分かると思うのですが...。

> >   なんかサイズがやけに違うのが気になりますが、Slackware にならって
> >
> > $ su
> > # cd /usr/lib
> > # ln -s ../../lib/libpthread.so.0 libpthread.so
> > 
> > してから configure をやり直すと無事終了しました。
> 
> うーむ、、/lib/libpthread.so があっても /usr/lib/libpthread.so が必要
> になるのかなぁ。。

  そうですよね。/usr/lib になければ /lib を探しますよね。
何か変だとは思っていたのですが、先のメールでは目先の問題解決を優先
していたので、深く追求せず、とりあえずの解決 (回避？) 策としてポスト
しちゃいました。

  で、納得いかないという事で、/lib, /usr/lib をぐりぐりといじりながら
もう少し調べてみました。
# 以下、次の 2 つのサンプルソースを使用します。
# ひとつは test_pthread.c (pthread ライブラリを使用する簡単なソース)
# もうひとつは test_system.c (system() 関数をコールするだけのソース)
# 現象とは無関係な (ように思われる) ので、コードは省略します。

  その結果、どうやら /usr/lib/libpthread.a がなにか悪さをしている
らしい事が分かりました。

  1) /usr/lib/libpthread.a を残し、その他の libpthread* をすべて削除。
     この状態だと...
     gcc test_pthread.c -lpthread   --> コンパイル OK, 動作 NG
     gcc test_system.c -lpthread    --> コンパイル OK, 動作 NG

     動作 NG とは、実行しても途中で止まってしまう。こんな感じ。

     (gdb) run
     Starting program: ./a.out 
     warning: Unable to find dynamic linker breakpoint function.
     warning: GDB will be unable to debug shared library initializers
     warning: and track explicitly loaded dynamic code.
     Linux thread target has modified Unknown signal handling

     (Ctrl + C で止めた)
     Program received signal SIGINT, Interrupt.
     0x400354e5 in sigsuspend ()
     (gdb) bt
     #0  0x400354e5 in sigsuspend ()
     #1  0x804d16d in __pthread_lock ()
     #2  0x804d59a in __pthread_mutex_lock ()
     #3  0x40037974 in atexit ()
     #4  0x400378e4 in __on_exit ()
     #5  0x804bb05 in pthread_initialize ()
     #6  0x804bb1c in __pthread_initialize ()
     #7  0x4006dbeb in _IO_file_xsputn ()
     #8  0x4006ddc4 in _IO_file_xsputn ()
     #9  0x4006e39f in malloc ()
     #10 0x400379be in atexit ()
     #11 0x40037924 in atexit ()
     #12 0x4002f2bf in __libc_start_main ()

     ldd の結果は以下の通り。
     $ ldd ./a.out (test_pthread の場合)
     libc.so.6 => /lib/libc.so.6 (0x40017000)
     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

  2) test_system.c は pthread なんか使ってないのに何故？ ということで...
     gcc test_system.c              --> コンパイル OK, 動作 OK

     もしくは、test_system.c から system() をコメントアウトすると...
     gcc test_system.c -lpthread    --> コンパイル OK, 動作 OK
     gcc test_system.c              --> コンパイル OK, 動作 OK

     (疑問 1) system() 関数を呼んでいると、なぜ -lpthread に影響される？
              使用しないライブラリを -lhoge しても無視されるだけじゃない
              のか？

  3) /usr/lib/libthread.so を復元 (実体は /lib/libpthread-0.8.so のコピー)
     し、ldconfig を実行 (/lib/libpthread* は何もなし) 。この状態だと...
     gcc test_pthread.c -lpthread   --> コンパイル OK, 動作 OK
     gcc test_system.c -lpthread    --> コンパイル OK, 動作 OK
     gcc test_system.c              --> コンパイル OK, 動作 OK

     ldd の結果は以下の通り。
     $ ldd ./a.out (test_pthread の場合)
     libpthread.so.0 => /usr/lib/libpthread.so.0 (0x40017000)
     libc.so.6 => /lib/libc.so.6 (0x40028000)
     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

     $ ldd ./a.out (test_system の場合)
     libpthread.so.0 => /usr/lib/libpthread.so.0 (0x40017000)
     libc.so.6 => /lib/libc.so.6 (0x40028000)
     /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)


  という訳で、先の xmms の configure 時の GTK+ 認識失敗の原因は、
/usr/lib/libpthread.so がないことではなく、-L/usr/lib -lpthread のため
/lib/libpthread.so ではなく /usr/lib/libpthread.a をリンクしていたため
のようです。具体的になにがどう、となると、この先どうやって調べようか、
ムムッとうなってしまうのですが...。(^^;

  ところで、ここで (疑問 2) なのですが、
/lib/libpthread* と /usr/lib/libpthread* 、何故 2 つあるのでしょう？
配置だけの問題でしょうか？ それともものが違う？

> > # あと libpthread のサイズがやけに小さいのも。Slack のは strip してない
> > # ということなのかしらん？？ それならいいけれど...。
> 
> 多分これは strip したかどうかの違いでしょうね。一応、plamo で入れてる
> のは少しでも小さくしようとライブラリの場合は strip -g でデバッグ用シン
> ボルを削るようにしています。

  そういう事ですか。ただ、この件なのですが、ソースからコンパイルしよう
とすると、いくつものライブラリ (libtiff とか libpng とか...) で no symbols
のため、./configure での認識に失敗 (たいていの場合は configure 中の
テストプログラム (conftest) のコンパイル／リンクに失敗することが原因
のようですが) してしまいます。

  失礼ですが、本当に strip -g なんでしょうか？ strip -g では no symbols
とはならないと思うのですが...。

# 例を挙げますと、お勧めパッケージをインストールした状態で、WindowMaker
# 0.62.1 をソースからコンパイルしようとすると、configure で libtiff が
# 認識されません。原因は /usr/lib/libtiff* が no symbols のため。
# libtiff をソースから入れ直すと問題なし。コンパイルし直した libtiff に
# strip -g しても no symbols とはならない。

-- 
// 深川 誠司 (Seiji Fukagawa)      | http://www1.plala.or.jp/fukafuka/
// XDriller 0.7.0 (α版) 公開中... | mailto: fukafuka@fsinet.or.jp