c - 各种 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 时使用的“最低内核版本”，则可以使用旧内核。但我不明白 反过来(使用旧内核头文件编译 GNU C 库并在最新内核上运行)不一定按预期工作。例如，如果您使用旧内核头文件编译 GNU C 库，则不能使用新内核功能。。这是唯一会发生在我身上的事吗？如果内核比编译时更新，它不会破坏 glibc 中的某些东西吗？

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

这么多问题 :) 谢谢!

Answer 1

1. 您不能轻易地(无论这个词的定义是什么)将较新的内核功能与旧版本的 glibc 一起使用。如果你真的需要，你可以直接调用系统调用(使用 syscall() 库函数)并从用户空间内核头文件(新内核中的东西)中挖掘任何必要的常量值和数据结构保存在 include/uapi 下)。另一方面，内核开发人员通常 promise 不会破坏较新内核中的遗留功能，因此较旧的 glibc 版本会继续按预期工作(好吧，差不多)。

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