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

在构建编译器时，除了glibc版本外，还必须指定Linux头版本和支持的最小内核版本。然后在目标机器上有实际的内核版本和glibc版本（有自己的内核头版本和支持的最小内核版本）。试图理解这些版本是如何结合在一起的，我感到相当困惑

示例1：假设我有一个基于内核头3.14构建的系统，其glibc2.13。这有什么意义吗？glibc 2.13（2011年发布）如何使用3.14（2014年发布）的新内核功能

示例2：假设我有一个glibc版本比2.13更新的编译器。编译后的程序能在GLIBC2.13系统上运行吗？如果编译器的glibc版本比2.13版本旧

例3：根据我的理解，如果旧内核满足编译glibc时使用的“最小内核版本”，则可以使用旧内核。但是我不理解这段话，相反（用旧内核头编译GNUC库并在新内核上运行）不一定能像预期的那样工作。例如，如果使用旧的内核头来编译GNUC库，则不能使用新的内核特性。。这是唯一能发生在我身上的事吗？如果内核比编译时更新，它不会破坏glibc中的某些东西吗

示例4：在glibc设置中做更细微的区别（例如，将根据内核头3.Y编译的glibc版本2.X的可执行文件与支持的最低内核版本2.6.A相链接，并使用相同的glibc 2.X在系统上执行，但根据支持的最低内核版本2.6.B的内核头3.Z编译）有什么影响吗？我想他们不是，但我想确定一下

这么多问题：）谢谢

您无法轻松地（无论单词的定义如何）将较新的内核功能与较旧版本的glibc一起使用。如果确实需要，您可以直接调用系统调用（使用

syscall（）

库函数），并从用户空间内核头（新内核中保存在

include/uapi

下）中挖掘所需的常量值和数据结构。另一方面，内核开发人员通常承诺不会破坏较新内核中的遗留功能，因此较旧的glibc版本仍能按预期工作（很好，几乎可以）

较旧的程序仍然使用较新版本的glibc，因为glibc支持符号的版本控制（有关详细信息，请参阅此处：）。如果您的程序在没有特殊规定的情况下与较新版本的glibc动态链接（如上面链接中所述），您将无法使用较旧版本的glibc库运行它（动态链接器将投诉未解析的符号，因为无法使用正确的符号版本）

---

我懂了。所以目标上的glibc不应该比我们联系的glibc老。但是内核呢？哪一个被认为包含“更新的内核特性”，例如，针对内核3.14编译的glibc2.13？内核2.6.38，因为它是在glibc 2.13之后发布的，或者3.15，因为它比我们编译的内核要新？您需要检查您正在使用的特定API。例如，在

epoll_ctl

中有一个众所周知的不兼容性，因此2.6.9之前的内核以不同的方式处理它的一个参数，这一事实反映在手册页中。对于大多数程序来说，没有什么可担心的，因为在过去10年中，大多数Linux API都相当稳定（udev和图形相关的东西除外）。谢谢，还有一点小说明：glibc 2.13可以使用哪些内核功能？它是否依赖于我构建glibc时使用的内核头版本？它不是这样工作的。回到epoll示例：手册页上说“在版本2.3.2中向glibc添加了支持”。因此，如果您有一个较旧的glibc，这意味着您将无法获得必要的include文件和库包装。其他非琐碎的东西也是一样。谢谢。因此，用新的内核头编译旧的glibc实际上没有意义（但也没有坏处），对吗