Warum haben die Bibliotheken glibc und pthread die gleichen APIs definiert?

Question

Warum glibc und pthread-Bibliothek beide definiert gleichen APIs? Hier ist die Snapshot-

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 Teil glibc zu, und sie enthalten beide (identischen) Definitionen einiger Symbole.

Wenn Sie pthread_create suchen stattdessen werden Sie sehen, dass es in libpthread.so nur vorhanden ist - das bedeutet, Programme zu libpthread.so verknüpfen müssen, um tatsächlich Threads zu erstellen , kann aber mutexes und Bedingungsvariablen in Single-Thread-Programme verwenden, die einzige Verbindung zu libc.so. Das ist nützlich für die Inter mutexes und Interbedingungsvariablen, die im gemeinsam genutzten Speicher leben und werden mit separaten Prozessen synchronisieren . (Korrekturen dank Zan Lynx Kommentar unten).

Es ist kein Problem, sowohl mit libpthread.so als auch mit libc.so zu verknüpfen, obwohl beide das Symbol definieren. ELF-Linker ermöglichen Bibliotheken mehr gemeinsamen Definitionen von demselben Symbol enthalten, und der Linker der ersten wählen sie sehen und es für alle Verweise auf dieses Symbol wird diese symbol interposition genannt. Ein weiteres Merkmal, das die Definition mehrerer Symbole erlaubt, ist, wenn eine Bibliothek weak symbols enthält, die von nicht-schwachen Symbolen mit dem gleichen Namen überschrieben wird. In diesem Fall wird die Definitionen in die beiden Bibliotheken sind identisch, so spielt es keine Rolle, welche libpthread.so Überschreibung verwendet wird, die in libc.so. Wenn Sie LD_DEBUG verwenden und die Reihenfolge der Argumente an den Linker ändern sollten Sie in der Lage sein zu sehen, welche Bibliothek das Symbol tatsächlich gefunden wird.

Neben den beiden Bibliotheken das gleiche Symbol definiert, jede Bibliothek hat zwei Definitionen des Symbols, mit unterschiedlichen symbol versions, GLIBC_2.0 und GLIBC_2.3.2. Diese Symbolversionierung ermöglicht die Koexistenz mehrerer Definitionen in derselben Bibliothek, sodass neue, verbesserte Versionen der Funktion der Bibliothek hinzugefügt werden können, ohne den Code zu unterbrechen, der mit der alten Implementierung verknüpft ist. Dadurch kann dieselbe gemeinsam genutzte Bibliothek für Anwendungen verwendet werden, die LinuxThreads und Anwendungen mit NPTL verwenden. Das Standardsymbol, an das eine Referenz gebunden wird, wenn es mit der Bibliothek verknüpft wird, ist pthread_cond_signal@GLIBC_2.3.2, was der NPTL Implementierung dieser Funktion entspricht (NPTL wurde zuerst in glibc 2.3.2 aufgenommen). Das ältere Symbol, pthread_cond_signal@GLIBC_2.0, ist die ältere LinuxThreads-Implementierung, die der Standard vor der Bereitstellung von NPTL war. Anwendungen, die mit älteren (vor 2.3.2) Versionen von glibc verbunden sind, werden an pthread_cond_signal@GLIBC_2.0 gebunden und verwenden dieses Symbol.