c - 了解 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”错误？我希望该程序现在需要 glibc 2.15，因为它是用 glibc 2.15 编译的。为什么程序也在寻找 glibc 2.11？这是否意味着我的程序将在两个 glibc 版本(即 2.15 和 2.11)上运行？所以它至少需要2.11？还是无论如何都需要 2.15？

另一个问题:glibc 向上兼容但向下兼容的假设是否正确？例如。使用 glibc 2.10 编译的程序是否保证可以与任何 future 版本的 glibc 完美配合？如果是这样的话，如果将来更改像 PATH_MAX 这样的常量会怎样？目前它设置为 4096，我正在使用 PATH_MAX 常量为 realpath() POSIX 函数分配缓冲区。现在，如果将来这个常量增加到 8192，可能会出现问题，因为我的程序只分配了 4096 字节。还是我误解了什么？

感谢您的解释!

Answer 1

Libc 使用符号版本控制。这是相当高级的魔法，但基本上每个符号都根据其出现的版本附加标签。如果它的语义发生变化，则有两个版本，一个用于旧语义及其首次出现的版本，另一个用于新语义及其出现的版本。加载程序只会提示您的程序实际请求的符号。有的刚好在2.15引入，有的刚好在2.11引入。

这样做的重点是保持 glibc 向后兼容。这真的很重要，因为有很多打包软件，所有这些都是动态链接的，重新编译所有这些软件会花费很长时间。还有很多软件没有可用的源代码，旧版本的 libc 可能不适用于新内核或其他新东西。

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

广告 PATH_MAX:如果完成这样的更改，glibc 将简单地导出使用新值的新版本符号和具有适当安全保障的旧版本符号，以使用针对旧值编译的代码。这是所有魔法的要点。