在构建编译器时，除了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我明白，如果它满足＆＃34;最小内核版本＆＃34;那么使用旧内核是可以的。在编译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 ）影响什么？我怀疑他们不是，但我想确定。
这么多问题:)谢谢！
答案 0 :(得分：6)
你不能轻易（对于这个词的任何定义）在较旧版本的glibc中使用较新的内核功能。如果你真的需要，你可以直接调用系统调用（使用syscall()库函数）并从用户空间内核头文件中挖掘所需的任何常量值和数据结构（新内核中的内容保存在{{ 1}}）。另一方面，内核开发人员通常承诺不会破坏较新内核中的遗留功能，因此较旧的glibc版本会按预期工作（好吧，差不多）。
较旧的程序仍然适用于较新版本的glibc，因为glibc支持符号的版本控制（有关详细信息，请参阅此处：https://www.kernel.org/pub/software/libs/glibc/hjl/compat/）。如果您的程序与较新版本的glibc动态链接而没有特殊规定（如上面的链接所述），您将无法使用较旧版本的glibc库运行它（动态链接器会抱怨未解析的符号，作为正确的符号版本将无法使用。）