各种glibc和Linux内核版本的兼容性
在构建编译器时，除了glibc版本之外，还必须指定Linux头版本和minumum支持的内核版本。然后在目标机器上有实际的内核版本和glibc版本(有自己的内核头版本和minumum支持的内核版本)。我很困惑试图理解这些版本是如何结合在一起的。
示例1:假设我的系统使用glibc 2.13构建在内核头3.14上。这说得通吗？glibc 2.13 (2011年发布)如何能够使用3.14 (2014年发布)的新内核特性？
示例2:假设我的编译器具有glibc版本的更新的，而不是2.13。编译后的程序会在glibc 2.13系统上工作吗？如果编译器的glibc版本是旧的而不是2.13
示例3:从used.3F中我了解到，如果旧内核满足在编译glibc时使用的"minumum内核版本“，就可以使用它。但我不明白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设置中是否存在更细微的差异(例如，将针对glibc版本2.X编译的可执行文件2.X与最小支持的内核版本2.6.A连接到系统上，使用相同的glibc 2.x在系统上执行，但使用minumum支持的内核版本2.6.B对内核标头3.Z进行编译)会有什么影响吗？我想他们不是，但我想确定。
这么多问题:)谢谢！
回答 1
Stack Overflow用户
发布于 2014-11-27 15:27:22
- 您不能轻易地使用更新的内核特性和较早版本的glibc (对于单词的任何定义)。如果确实需要，您可以直接调用系统调用(使用
syscall()库函数)，并从用户空间内核头中挖掘所需的常量值和数据结构(更新的内核中的内容保存在include/uapi下)。另一方面，内核开发人员通常承诺不会破坏较新内核中的遗留特性，因此旧的glibc版本仍然按预期工作(嗯，几乎)。 - 旧的程序仍然可以使用较新版本的glibc，因为glibc支持符号的版本控制(请参阅这里的一些详细信息：https://www.kernel.org/pub/software/libs/glibc/hjl/compat/)。如果您的程序与更新版本的glibc动态链接，而没有特殊规定(如上面的链接所述)，您将无法使用较旧版本的glibc库来运行它(动态链接器将抱怨未解决的符号，因为没有合适的符号版本)。
https://stackoverflow.com/questions/27171485
复制相似问题
腾讯云开发者
