我在运行内核2.6.26-2-amd64的Linux(Debian)的机器上构build应用程序,我想在运行Linux(Suse)的内核2.6.16.60-0.21-smp的另一台机器上运行此应用程序,但出现错误“致命的:内核太旧了”。
我从互联网上的研究中知道,这种情况可能会发生在针对glibc库进行构build时,该库并非为了支持较早的内核版本而编译的,而是通常涉及版本2.4。 是否有可能为同一系列的内核(2.6)获得这样的错误,或者可以从其他方面得到?
此外,我读了这个问题的解决scheme是重新编译与适当的–enable-kernel = VERSION选项编译的另一个版本的glibc的应用程序。 作为一种替代scheme,您可以将您的应用程序与glibcdynamic链接以解决问题?
感谢您的帮助。
更新 :我知道我的问题可能看起来模糊或解决已经提到的解决scheme之一(dynamic链接,build立在另一个[虚拟]系统,重buildglibc [这看起来相当棘手,考虑到我读的评论],但我是什么最终寻找的方法是防止这样的问题。
例如,是否有可能find哪个版本的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) [...]
这解释了“内核太旧”的错误。 希望它可以帮助别人。
确定给定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
”,它表示最小的内核版本。