glibc的头文件 linux_各种glibc和Linux内核版本的兼容性

在构建编译器时,除了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设置中做更细微的差别(例如,将可执行文件与针对内核头文件3.Y编译的glibc版本2.X链接到最小支持内核版本2.6.A并在具有相同glibc 2.X的系统上执行,但针对内核头文件编译3.Z与minumum支持内核版本2.6.B)影响什么？我怀疑他们不是,但我想确定.

这么多问题:)谢谢！

>你不能轻易(对于这个词的任何定义)使用旧版本的glibc更新的内核功能.如果你真的需要,你可以直接调用系统调用(使用syscall()库函数)并从用户空间内核头文件中挖掘所需的任何常量值和数据结构(在较新的内核中包含的内容包括/ uapi) .另一方面,内核开发人员通常承诺不会破坏较新内核中的遗留功能,因此较旧的glibc版本会按预期工作(好吧,差不多).

>较旧的程序仍然适用于较新版本的glibc,因为glibc支持符号的版本控制(有关详细信息,请参见此处：

https://www.kernel.org/pub/software/libs/glibc/hjl/compat/).如果您的程序与较新版本的glibc动态链接而没有特殊规定(如上面的链接所述),您将无法使用较旧版本的glibc库运行它(动态链接器将抱怨未解析的符号,作为正确的符号版本将无法使用).