[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[plamo:06851] Re: Don't exist /usr/lib/libpthread.so
-
From:Seiji Fukagawa
-
Date:Sat, 19 Aug 2000 22:03:31 +0900
- Subject: [plamo:06851] Re: Don't exist /usr/lib/libpthread.so
- From: Seiji Fukagawa <fukafuka@xxxxxxxxxxxx>
- Date: Sat, 19 Aug 2000 22:03:31 +0900
- Posted: Sat, 19 Aug 2000 22:04:03 +0900
深川です。
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
- Follow-Ups
-
- [plamo:06854] Re: Don't exist /usr/lib/libpthread.so, Hiroki Ishihara
- [plamo:06862] Re: Don't exist /usr/lib/libpthread.so, KOJIMA Mitsuhiro
- [plamo:06906] Re: Don't exist /usr/lib/libpthread.so, KOJIMA Mitsuhiro
- References
-
- [plamo:06814] Don't exist /usr/lib/libpthread.so, Seiji Fukagawa
- [plamo:06827] Re: Don't exist /usr/lib/libpthread.so, KOJIMA Mitsuhiro
[検索ページ]
[メール一覧]
Plamo ML 公開システム