共享库：为什么在一个二进制文件中有多个版本的 GLIBC答案

【问题标题】：Shared libaray : Why muliple versions of GLIBC_ in a single binary共享库：为什么在一个二进制文件中有多个版本的 GLIBC
【发布时间】：2012-06-21 13:20:44
【问题描述】：

上下文：我目前正在调试一个问题，即在一台机器上生成的二进制文件（与 lpthread 类似）在另一台机器上尝试时会导致与 pthread 相关的错误。

libtest.so 是一个共享库，它似乎包含多个版本的 GLIBC_ 。这是预期的吗？它是怎么发生的？它是使用“-shared -lpthread -fPIC -soname=xxxx”选项链接的。

$objdump -T libtest.so | grep GLIBC_

... 
00000000      DF *UND*  0000008d  GLIBC_2.1   popen
...
00000000      DF *UND*  0000002c  GLIBC_2.0   syslog
00000000      DF *UND*  00000020  GLIBC_2.0   pthread_exit
00000000      DF *UND*  0000009f  GLIBC_2.0   __xstat
00000000      DF *UND*  000000bb  GLIBC_2.3.2 pthread_cond_signal
00000000      DF *UND*  000000c9  GLIBC_2.0   vsprintf
...

【问题讨论】：

标签： c linux gcc linker

【解决方案1】：

每个符号都有自己的历史。

当一个符号没有被修改（签名、行为）时，它保持默认版本，例如。 GLIBC_2.0。修改的符号归属于当时库的当前版本，例如popen()行为在GLIBC_2.1中被修改，pthread_cond_signal()在GLIBC_2.3.2中被修改。

您的程序与每个符号的最新版本相关联。版本被记录下来，如果您针对较新的 GLIBC 运行程序，您的程序将不会使用较新的符号版本，而是在链接时可用的版本：这确保在运行时具有预期的行为：不足为奇。

【讨论】：

如果运行.so文件的系统没有 GLIBC_2.3.2 ，只有 GLIBC_2.0 怎么办？会报错还是改用GLIBC_2.0？
@LunarMushrooms 运行时会报错：symbol not found。
看看stackoverflow.com/questions/2856438/…或stackoverflow.com/questions/4032373/…

【解决方案2】：

那是因为这些方法存在于不同的 .so 中。 glibc 是 .so 的集合。我相信pthread_exit 在libpthread.so 中，popen 在libc.so 中

【讨论】：

好的。例如“GLIBC_2.3.2 pthread_cond_signal”期望 GLIBC_2.3.2 版本的 pthread 可用，对吗？当我将此 libtest.so 复制到该机器时，如果另一台机器具有不同版本的 pthread 怎么办？它会起作用吗？我怎么知道第二台机器使用 GLIBC_2.3.2 ？