¿Por qué las bibliotecas glibc y pthread definieron las mismas API?

Question

¿Por qué las bibliotecas glibc y pthread definieron las mismas API? Aquí es la instantánea

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 es parte de glibc también, y que ambos contienen (idénticos) definiciones de algunos símbolos.

Si nos fijamos para pthread_create vez verá que es sólo presente en libpthread.so - esto significa programas deben enlazar a libpthread.so para realmente crear hilos , pero se pueden utilizar mutex y variables de condición en programas de un solo subproceso que sólo enlace a libc.so. Esto es útil para muteos entre procesos y variables de condición entre procesos que viven en memoria compartida y se usan para sincronizar con procesos separados . (correcciones gracias al comentario de Zan Lynx a continuación).

No es un problema vincular a libpthread.so y libc.so aunque ambos definen el símbolo. Los vinculadores ELF permiten que varias bibliotecas compartidas contengan definiciones del mismo símbolo y el vinculador elegirá la primera que ve y la utilizará para todas las referencias a ese símbolo, esto se llama symbol interposition. Otra característica que permite que se definan varios símbolos es si una biblioteca contiene weak symbols, que será reemplazada por símbolos no débiles con el mismo nombre. En este caso, las definiciones en las dos bibliotecas son idénticas, por lo que no importa cuál sea el utilizado libpthread.so, anule las que están en libc.so. Si utiliza LD_DEBUG y cambiar el orden de los argumentos al enlazador usted debería ser capaz de ver qué biblioteca el símbolo realidad se encuentra en.

Además de las dos bibliotecas que definen el mismo símbolo, cada biblioteca tiene dos definiciones del símbolo, con diferente symbol versions, GLIBC_2.0 y GLIBC_2.3.2. Este control de versiones de símbolos permite que varias definiciones coexistan en la misma biblioteca para que las nuevas versiones mejoradas de la función se agreguen a la biblioteca sin romper el código vinculado a la implementación anterior. Esto permite que la misma biblioteca compartida funcione para aplicaciones que usan LinuxThreads y aplicaciones que usan NPTL. El símbolo predeterminado al que se vinculará una referencia al vincular a la biblioteca es pthread_cond_signal@GLIBC_2.3.2 que corresponde a la implementación NPTL de esa función (NPTL se incluyó por primera vez en glibc 2.3.2). El símbolo anterior, pthread_cond_signal@GLIBC_2.0, es la implementación anterior de LinuxThreads que era la predeterminada antes de que se proporcionara NPTL. Las aplicaciones vinculadas a versiones anteriores (anteriores a la 2.3.2) de glibc se vincularán a pthread_cond_signal@GLIBC_2.0 y utilizarán ese símbolo.