在构建编译器时，除了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.X 链接，最低支持的内核版本 2.6.A 并在具有相同 glibc 2.X 的系统上执行，但针对内核头 3.Z 编译，内核版本最低支持的内核版本 2.6.B）是否会影响任何事情？我怀疑他们不是，但想确定一下。
这么多问题:)谢谢！
-
您不能轻易地（无论这个词的定义是什么）将较新的内核功能与较旧版本的 glibc 一起使用。如果你真的需要，你可以直接调用系统调用（使用
syscall()库函数），并从用户空间内核头中挖掘任何必要的常量值和数据结构（在较新的内核中保存在include/uapi下的东西）。另一方面，内核开发人员通常承诺不会破坏较新内核中的遗留功能，因此较旧的 glibc 版本可以按预期工作（嗯，几乎）。
较 旧的程序仍然可以使用较新版本的 glibc，因为 glibc 支持符号的版本控制（有关一些详细信息，请参阅此处：https://www.kernel.org/pub/software/libs/glibc/hjl/compat/）。如果您的程序在没有特殊规定的情况下与较新版本的 glibc 动态链接（如上面的链接中所述），您将无法使用旧版本的 glibc 库运行它（动态链接器会抱怨未解析的符号，因为正确的符号版本将不可用）。