15

なぜglibcとpthreadライブラリの両方が同じAPIを定義したのですか？これがスナップショットです

ubuntu@ubuntu:/lib$ objdump -T /lib/i386-linux-gnu/libc.so.6 |grep pthread_cond_signal
000f8360 g    DF .text  00000039  GLIBC_2.3.2 pthread_cond_signal
0012b940 g    DF .text  00000039 (GLIBC_2.0)  pthread_cond_signal

ubuntu@ubuntu:/lib$ objdump -T /lib/i386-linux-gnu/libpthread.so.0 |grep pthread_cond_signal
0000b350 g    DF .text  0000007c (GLIBC_2.0)  pthread_cond_signal
0000af90 g    DF .text  000000fc  GLIBC_2.3.2 pthread_cond_signal
4

1 に答える 1

16

libpthread.soも glibc の一部であり、どちらにもいくつかのシンボルの(同一の)定義が含まれています。

代わりにを探すと、pthread_createにのみ存在することがわかります。libpthread.soこれは、プログラムlibpthread.soが実際にスレッドを作成するには にリンクする必要がありますが、 にのみリンクするシングルスレッド プログラムでミューテックスと条件変数を使用できることを意味しlibc.soます。これは、共有メモリに存在し、別のプロセスと同期するために使用されるプロセス間ミューテックスおよびプロセス間条件変数に役立ちます。(以下の Zan Lynx のコメントによる訂正)。

libpthread.so両方にリンクしても問題ありませんlibc.so。両方がシンボルを定義していても問題ありません。ELF リンカを使用すると、複数の共有ライブラリに同じシンボルの定義を含めることができ、リンカは最初に検出したものを選択し、そのシンボルへのすべての参照に使用します。これは、シンボル挿入と呼ばれます。複数のシンボルを定義できるもう 1 つの機能は、1 つのライブラリに、同じ名前の非ウィーク シンボルによって上書きされるウィーク シンボルが含まれている場合です。この場合、2 つのライブラリの定義は同一であるため、どちらを使用して の定義をオーバーライドしても問題ありません 。リンカーへの引数の順序を変更して使用する場合libpthread.solibc.soLD_DEBUG シンボルが実際に見つかったライブラリを確認できるはずです。

同じシンボルを定義する 2 つのライブラリと同様に、各ライブラリには、シンボル バージョンが異なる と の 2 つのシンボル定義がありGLIBC_2.0ますGLIBC_2.3.2。このシンボルのバージョン管理により、複数の定義を同じライブラリに共存させることができるため、古い実装にリンクされているコードを壊すことなく、関数の新しく改善されたバージョンをライブラリに追加できます。これにより、LinuxThreads を使用するアプリケーションと NPTL を使用するアプリケーションで同じ共有ライブラリを使用できます。ライブラリへのリンク時に参照がバインドされるデフォルトのシンボルは、その関数のNPTLpthread_cond_signal@GLIBC_2.3.2実装に対応します (NPTL は glibc 2.3.2 に最初に含まれました)。古いシンボル、pthread_cond_signal@GLIBC_2.0は、NPTL が提供される前のデフォルトであった古い LinuxThreads 実装です。古い (2.3.2 より前の) バージョンの glibc にリンクされたアプリケーションpthread_cond_signal@GLIBC_2.0は、そのシンボルにバインドされ、使用されます。

于 2012-06-26T15:13:39.940 に答える