为什么glibc和pthread库都定义了相同的API?

Lun*_*oms 12 linux gcc glibc pthreads

为什么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
Run Code Online (Sandbox Code Playgroud)

Jon*_*ely 13

libpthread.so也是glibc的一部分,它们都包含某些符号的(相同)定义.

如果你寻找它,pthread_create你会发现它只存在于libpthread.so- 这意味着程序必须链接libpthread.so到实际创建线程,但可以在仅链接到的单线程程序中使用互斥锁和条件变量libc.so.这对于处理共享内存并用于与单独进程同步的进程间互斥和进程间条件变量很有用.(感谢Zan Lynx在下面的评论).

链接到两者并不是一个问题libpthread.so,libc.so即使它们都定义了符号.ELF链接器允许多个共享库包含相同符号的定义,链接器将选择它看到的第一个,并将其用于对该符号的所有引用,这称为符号插入.允许定义多个符号的另一个特征是,如果一个库包含弱符号,这些弱符号将被具有相同名称的非弱符号覆盖.在这种情况下,在定义的两个库是相同的,所以它并不重要,其是用来 libpthread.so覆盖在libc.so.如果您使用LD_DEBUG 并更改链接器的参数顺序,您应该能够看到符号实际找到的库.

除了定义相同符号的两个库之外,每个库还有两个符号定义,具有不同的符号版本,GLIBC_2.0以及GLIBC_2.3.2.此符号版本控制允许多个定义共存于同一个库中,以便将新的,改进的函数版本添加到库中,而不会破坏与旧实现链接的代码.这允许相同的共享库适用于使用LinuxThreads的应用程序和使用NPTL的应用程序.链接到库时引用将绑定的默认符号与该函数pthread_cond_signal@GLIBC_2.3.2NPTL实现相对应(NPTL首先包含在glibc 2.3.2中).较旧的符号pthread_cond_signal@GLIBC_2.0是旧的LinuxThreads实现,它是在提供NPTL之前的默认实现.与旧版(2.3.2之前版本)glibc相关联的应用程序将绑定pthread_cond_signal@GLIBC_2.0并将使用该符号.

  • 我不相信这个答案是完全正确的.glibc中的定义只是占位符,并且对于pthread操作只有空的do-nothing定义.libpthread.so中的定义会覆盖这些定义.这适用于想要在多线程程序中快速进行单线程但线程安全的库. (7认同)