各种 glibc 和 Linux 内核版本的兼容性

Question

在构建编译器时，除了 glibc 版本之外，还必须指定 Linux 头文件版本和最低支持的内核版本。然后在目标机器上有实际的内核版本和 glibc 版本（具有自己的内核头文件版本和最低支持的内核版本）。我很困惑试图理解这些版本是如何结合在一起的。

示例 1：假设我有针对内核头文件 3.14 构建的带有 glibc 2.13 的系统。这有任何意义吗？ glibc 2.13（2011 年发布）如何使用 3.14（2014 年发布）的新内核功能？

示例 2：假设我有一个 glibc 版本更新比 2.13 的编译器。编译的程序可以在带有 glibc 2.13 的系统上运行吗？如果编译器的 glibc 版本比 2.13旧？

示例 3：来自https://sourceware.org/glibc/wiki/FAQ#What_version_of_the_Linux_kernel_headers_should_be_used.3F 我了解到，如果它满足编译 glibc 时使用的“最低内核版本”，则可以使用旧内核。但是我不明白The other way round (compiling the GNU C library with old kernel headers and running on a recent kernel) does not necessarily work as expected. For example you can't use new kernel features if you used old kernel headers to compile the GNU C library.的段落。这是唯一可能发生在我身上的事情吗？如果内核比编译时更新，它不会破坏 glibc 中的某些内容吗？

示例 4：在 glibc 设置中做更细微的区别（例如，将可执行文件与根据内核头文件 3.Y 编译的 glibc 版本链接内核版本 2.6.A 并在具有相同 glibc 2.X 的系统上执行，但针对内核头文件 3.Z 编译并支持最小值内核版本 2.6.B) 有什么影响吗？我怀疑他们不是，但想确定一下。

这么多问题 :) 谢谢！

Answer 1

1. 你不能轻易地（对于这个词的任何定义）在旧版本的 glibc 中使用更新的内核特性。如果您确实需要，您可以直接调用系统调用（使用syscall() 库函数）并从用户空间内核头文件中挖掘所需的任何常量值和数据结构（新内核中的内容保存在include/uapi 下） .另一方面，内核开发人员通常承诺不会破坏较新内核中的遗留功能，因此较旧的 glibc 版本会继续按预期工作（嗯，几乎）。

2. 较旧的程序仍然可以使用较新版本的 glibc，因为 glibc 支持符号版本控制（有关详细信息，请参阅此处：https://www.kernel.org/pub/software/libs/glibc/hjl/compat/）。如果您的程序在没有特殊规定的情况下与新版本的 glibc 动态链接（如上面的链接中所述），您将无法使用旧版本的 glibc 库运行它（动态链接器将抱怨未解析的符号，作为正确的符号版本将不可用）。