理解glibc

Question

我想将我的程序分发为二进制文件,而不是源代码形式.我有两个测试系统:较旧的Linux(带有glibc 2.10的openSUSE 11.2)和最近的一个(带有glibc 2.15的LinuxMint 13).现在,当我使用glibc 2.15在LinuxMint系统上编译我的程序,然后尝试使用glibc 2.10在openSUSE系统上启动二进制文件时,我得到以下两个错误:

./a.out: /lib/libc.so.6: version 'GLIBC_2.15' not found (required by ./a.out)
./a.out: /lib/libc.so.6: version 'GLIBC_2.11' not found (required by ./a.out)

让我感到困惑的是:为什么我这里也会收到"glibc 2.11 not found"错误？我希望程序现在需要glibc 2.15,因为它已经用glibc 2.15编译.为什么程序也在寻找glibc 2.11？这是否意味着我的程序将在两个glibc版本上运行,即2.15和2.11？所以它需要至少2.11？或者它在任何情况下都需要2.15？

另一个问题:假设是否正确,glibc是向上兼容但不向下兼容？例如,使用glibc 2.10编译的程序可以保证与glibc的任何未来版本完美配合吗？如果是这种情况,如果将来改变像PATH_MAX这样的常量会发生什么？目前设置为4096,我使用PATH_MAX常量为realpath()POSIX函数分配缓冲区.现在如果将来这个常量提高到8192,可能会出现问题,因为我的程序只分配了4096个字节.或者我在这里误解了什么？

谢谢你的解释!

Answer 1

Libc使用符号版本控制.它是相当高级的魔法,但基本上每个符号都根据它出现的版本附加标签.如果它的语义发生了变化,那么有两个版本,一个是旧语义,第一个出现的版本,另一个是新语义和出现的版本.加载器只会抱怨程序实际请求的符号.其中一些恰好在2.15中引入,其中一些恰好在2.11中引入.

这一点的重点是保持glibc向后兼容.这非常重要,因为有很多打包的软件,它们都是动态链接的,重新编译所有这些都需要很长时间.还有许多软件没有可用的源代码,旧的libc版本可能无法与新内核或其他新内容一起使用.

所以是的,glibc是向后兼容的.只需确保针对运行时需要它的最旧版本进行编译,因为它不能(也不能)向前兼容.

Ad PATH_MAX:如果完成了类似的更改,glibc将只导出使用新值的符号的新版本和具有适当安全值的旧版本符号,以使用针对旧值编译的代码.这是所有魔法的主要观点.