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

为什么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 

Solutions Collecting From Web of "为什么glibc和pthread库都定义了相同的API?"

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

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

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

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