预期2.6.16和2.6.26内核版本之间的“内核太旧”错误
我在运行带有内核2.6.26-2-amd64的Linux(Debian)的计算机上构建了一个应用程序,我想在运行运行内核2.6.16.60-0.21-smp的Linux(Suse)的另一台计算机上运行此应用程序,但是出现了错误“致命:内核太旧”。
我从互联网上的研究中得知,如果针对未编译为支持较早内核版本的glibc库进行构建,则可能会发生这种情况,但它通常涉及2.4版。是否有可能针对相同系列(2.6)的内核获得此类错误,或者可能是其他原因引起的?
另外,我读到该问题的解决方案是针对使用适当的–enable-kernel =
VERSION选项编译的glibc的另一个版本重建应用程序。作为替代方案,您可以将应用程序与glibc动态链接以解决问题吗?
感谢您的帮助。
:我理解我的问题似乎已经被提到的解决方案之一模糊或解决了(动态链接,在另一个[虚拟]系统上构建,重建glibc
[考虑到我所读到的评论,这似乎很棘手])但是我是什么最终寻找预防此类问题的方法。
例如,是否可以找到与特定版本的glibc兼容的Linux内核版本?
:我最终找到了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
”,它表示最低内核版本。
以上是 预期2.6.16和2.6.26内核版本之间的“内核太旧”错误 的全部内容, 来源链接: utcz.com/qa/400466.html