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

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

示例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的系统上执行，但针对最低支持的内核版本2.6.B的内核 header 3.Z进行编译会产生什么影响？我怀疑它们不是，但想确定。

这么多问题:)谢谢!

最佳答案

您不能轻易(对于单词的任何定义)在较旧的glibc版本中使用较新的内核功能。如果确实需要，您可以直接调用系统调用(使用syscall()库函数)，并从用户空间内核 header (较新内核中的内容保存在include/uapi下)中挖掘出任何常量值和数据结构。另一方面，内核开发人员通常会保证不会破坏新内核中的旧功能，因此较旧的glibc版本仍能按预期运行(几乎)。

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