1

コンテキスト：現在、あるマシンで生成されたバイナリ（lpthreadと同様）が別のマシンで試行されたときにpthread関連のバグを引き起こす問題をデバッグしています。

libtest.soは、GLIBC_の複数のバージョンが含まれているように見える共有ライブラリです。それは期待されていますか？それはどのように起こりますか？「-shared-lpthread-fPIC-soname=xxxx」オプションを使用してリンクされました。

$objdump -T libtest.so | grep GLIBC_

... 
00000000      DF *UND*  0000008d  GLIBC_2.1   popen
...
00000000      DF *UND*  0000002c  GLIBC_2.0   syslog
00000000      DF *UND*  00000020  GLIBC_2.0   pthread_exit
00000000      DF *UND*  0000009f  GLIBC_2.0   __xstat
00000000      DF *UND*  000000bb  GLIBC_2.3.2 pthread_cond_signal
00000000      DF *UND*  000000c9  GLIBC_2.0   vsprintf
...
4

2 に答える 2

4

各シンボルには独自の履歴があります。

シンボルが変更されていない場合（署名、動作）、デフォルトバージョンが保持されます。GLIBC_2.0。変更されたシンボルは、その時点でのライブラリの現在のバージョンに起因します。たとえば、popen（）の動作はGLIBC_2.1で変更され、pthread_cond_signal（）はGLIBC_2.3.2で変更されました。

プログラムは、各シンボルの最新バージョンにリンクされます。バージョンが記録され、新しいGLIBCに対してプログラムを実行した場合、プログラムは新しいシンボルバージョンを使用しませんが、リンク時に使用可能なバージョンを使用します。これにより、実行時に期待される動作が保証されます。当然のことです。

于 2012-06-21T13:34:48.157 に答える
0

これは、これらのメソッドが異なる .so に存在するためです。glibc は .so のコレクションです。I think is pthread_exitinlibpthread.soと popen is inlibc.so

于 2012-06-21T13:25:34.850 に答える