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

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.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

该符号并将使用该符号。