预测2.6.16和2.6.26内核版本之间的"内核太旧"错误

Question

我使用内核2.6.26-2-amd64在运行Linux(Debian)的机器上构建应用程序,我想在运行Linux(Suse)的另一台机器上运行此应用程序,内核为2.6.16.60-0.21-smp,但是我收到错误"致命:内核太旧".

我从互联网上的研究中得知,这可能发生在针对未编译为支持旧内核版本的glibc库构建时,但它通常涉及2.4版本.是否有可能为同一系列的内核(2.6)获取此类错误,或者这可能来自其他内容？

另外我读到这个问题的解决方案是使用适当的--enable-kernel = VERSION选项编译的另一个版本的glibc重建应用程序.作为替代方案,您可以动态地将您的应用程序与glibc链接以解决问题吗？

谢谢您的帮助.

更新:我理解我的问题可能看似含糊不清或已经提到的解决方案之一(动态链接,建立在另一个[虚拟]系统上,重建glibc [考虑到我读到的关于它的评论看起来相当棘手])但是我是什么最终寻找是预防此类问题的方法.

例如,是否有可能找到哪些版本的Linux内核与特定版本的glibc兼容？

更新2:我最终找到了glibc的源补丁(对于Debian,但我猜其他发行版有类似的在线文档)(我猜)包含我正在寻找的信息.

从这个页面:

--- eglibc-2.11.2.orig/debian/sysdeps/linux.mk
+++ eglibc-2.11.2/debian/sysdeps/linux.mk
@@ -0,0 +1,51 @@
[...]
+MIN_KERNEL_SUPPORTED := 2.6.18
[...]
+# Minimum Kernel supported
+with_headers = --with-headers=$(shell pwd)/debian/include
--enable-kernel=$(call xx,MIN_KERNEL_SUPPORTED)
[...]

这解释了"内核太老"的错误.希望它能帮助其他人.

Answer 1

确定给定ELF文件的最小内核版本的一种方法是file在其上运行,如下所示:

$ echo 'int main(){}' > test.c
$ gcc -o test test.c
$ file test
test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.38, not stripped

这里的重要部分是" for GNU/Linux 2.6.38",表示最小内核版本.