glibcとpthreadライブラリの両方で同じAPIが定義されているのはなぜですか？

Question

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 

Answer 1

libpthread.soものglibcの一部であり、彼らは両方のいくつかのシンボルの （同一） 定義が含まれています。

あなたの代わりにpthread_createを探している場合、あなたはそれがlibpthread.soにのみ存在だということがわかります - これは、プログラムが実際にスレッド を作成するために libpthread.soにリンクしなければならないことを意味、それだけリンクシングルスレッドのプログラムでミューテックスと条件変数を使用することができます libc.so。これは、共有メモリに存在し、別のプロセスとの同期に使用されるプロセス間mutexとプロセス間の条件変数に便利です 。 （下のZan Lynxのコメントに感謝します）。

シンボルが両方とも定義されていても、libpthread.soとlibc.soの両方にリンクすることは問題ありません。 ELFリンカは、いくつかの共有ライブラリに同じシンボルの定義を含めることができます。リンカは最初に見たものを選択し、そのシンボルへのすべての参照に使用します。これはsymbol interpositionです。複数のシンボルを定義できるもう1つの機能は、1つのライブラリに同じ名前の非弱いシンボルで上書きされるweak symbolsが含まれている場合です。この場合、 の定義は2つのライブラリが同一であるため、 libpthread.soのどちらを使用するかは関係ありません。libc.soの定義を上書きします。あなたがLD_DEBUG を使用して、リンカ に引数の順序を変更する場合は、シンボルが実際にありますどのライブラリを参照することができるはずです。

と同様に同じシンボルを定義する2つのライブラリーは、各ライブラリは、二つの定義がありますがシンボルのうち、異なるものがsymbol versions、GLIBC_2.0、およびGLIBC_2.3.2です。このシンボルのバージョニングにより、複数の定義を同じライブラリに共存させることができるので、関数の新しく改良されたバージョンを、古い実装とリンクされたコードを破ることなくライブラリに追加することができます。これにより、NPTLを使用するLinuxThreadおよびアプリケーションを使用するアプリケーションで同じ共有ライブラリを使用できます。ライブラリにリンクするときに参照がバインドされる既定のシンボルは、その機能のNPTL実装に対応するpthread_cond_signal@GLIBC_2.3.2です（NPTLは最初にglibc 2.3.2に含まれていました）。古いシンボルpthread_cond_signal@GLIBC_2.0は、NPTLが提供される前のデフォルトのLinuxThreads実装です。 glibcの古いバージョン（2.3.2より前のバージョン）にリンクされたアプリケーションはpthread_cond_signal@GLIBC_2.0にバインドされ、そのシンボルが使用されます。