为什么glibc和pthread库都定义了相同的API?
为什么glibc和pthread库都定义了相同的API?这是快照
ubuntu@ubuntu:/lib$ objdump -T /lib/i386-linux-gnu/libc.so.6 |grep pthread_cond_signal000f8360 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
回答:
libpthread.so
也是glibc的一部分,它们都包含某些符号的 (相同) 定义。
如果您要查找,pthread_create
则会发现它仅存在于libpthread.so
-这意味着程序必须链接libpthread.so
到实际创建的线程
,但是可以在仅链接到的单线程程序中使用互斥体和条件变量。(由于下面的Zanlibc.so
。这对于共享内存中存在的进程间互斥锁和进程间条件变量很有用,并用于与单独的进程进行同步
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.2
对应于该函数的NPTL实现(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库都定义了相同的API? 的全部内容, 来源链接: utcz.com/qa/423890.html