了解glibc

Question

我想以二进制形式分发我的程序，而不是以源代码的形式。我有两个测试系统:一个是旧的openSUSE(带有glibc2.10的Linux11.2)和最近的(带有glibc2.15的LinuxMint 13 )。现在，当我使用glibc2.15在LinuxMint系统上编译我的程序，然后尝试在openSUSE系统上使用glibc2.10启动二进制文件时，我得到了以下两个错误：

./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将简单地导出使用新值的新版本符号和具有适当安全标记的旧版本符号，以使用针对旧值编译的代码。这就是所有魔法的要点。