理解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将只导出使用新值的符号的新版本和具有适当safegurads的旧版本符号，以使用针对旧值编译的代码。 这是所有魔法的主要观点。