预测“内核太旧” 2.6.16和2.6.26内核版本之间的错误 [英] Anticipate "kernel too old" errors between 2.6.16 and 2.6.26 kernel versions

问题描述

我在运行Linux（Debian）的机器上使用内核2.6.26-2-amd64构建应用程序，我想在运行Linux（Suse）的另一台机器上运行这个应用程序，内核2.6.16.60-0.21-smp但是我得到错误致命：内核太旧。

我从互联网上的研究知道，这可能发生时构建一个glibc库，没有编译支持老内核版本，但它通常涉及版本2.4。是否可能获得同一系列内核的这样的错误（2.6）或者可以从其他的？

此外，我读到这个问题的解决方案是针对另一个使用适当的--enable-kernel = VERSION选项编译的glibc版本重建应用程序。作为一个替代方法，你只是动态链接你的应用程序与glibc来解决问题？

感谢您的帮助。

UPDATE ：我理解我的问题可能似乎模糊或解决已经提到的解决方案之一（动态链接，构建在另一个[虚拟]系统上，重建glibc [这似乎很棘手，我读了关于它]），但我最终寻找的是防止这样的问题的方法。

例如，是可能找到哪些版本的Linux内核：我最终找到了一个glibc的源代码补丁（对于Debian，但我猜是有类似的docs在线其他发行）（我猜）包含我正在寻找的信息。

从此页：

  --- 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 
 [...] 
 +＃支持的最小内核
 + 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位LSB可执行文件，x86-64，版本1（SYSV），动态链接libs），对于GNU / Linux 2.6.38，未剥离
  

这里的重要部分是 code> for GNU / Linux 2.6.38 ，表示最小内核版本。

I build an application on a machine running Linux (Debian) with kernel 2.6.26-2-amd64 and I want to run this application on another machine running Linux (Suse) with kernel 2.6.16.60-0.21-smp but I get the error "FATAL: kernel too old".

I know from research on the internet that this can happen when building against a glibc library that was not compiled to support older kernel versions, but it usually concerns version 2.4. Is it possible to get such errors for kernel of the same series (2.6) or can this be from something else ?

Additionally I read that the solution to this problem is to rebuild the application against another version of glibc compiled with appropriate --enable-kernel=VERSION option. As an alternative can you just dynamically link your application with glibc to solve the problem ?

Thank you for your help.

UPDATE: I understand my question may seem vague or solved by one of the solutions already mentionned (dynamically linking, building on another [virtual] system, rebuilding glibc [which seems quite tricky considering the comments I read about it]) but what I am ultimately looking for are ways to prevent such problems.

For instance, is it possible to find which versions of the Linux kernel are compatible with a particular build of glibc ?

UPDATE 2: I eventually found a source patch for glibc (for Debian but I guess there are similar docs online for other distros) that (I guess) contains the information I was looking for.

From this page:

--- 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)
[...]

Which explains the "kernel too old" error. Hope it helps other people.

解决方案

One way you can determine the minimum kernel version for a given ELF file is to run file on it, like so:

$ 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

The important part here is the "for GNU/Linux 2.6.38", which indicates the minimum kernel version.

这篇关于预测“内核太旧” 2.6.16和2.6.26内核版本之间的错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！