预测 2.6.16 和 2.6.26 内核版本之间的"kernel too old"错误

Question

我在一台运行Linux (Debian)内核2.6.26-2-amd64的机器上构建了一个应用程序，我想在另一台运行Linux (Suse)内核2.6.16.60-0.21-smp的机器上运行这个应用程序，但我得到错误"FATAL: kernel too old"

我从互联网上的研究中知道，当针对未编译为支持旧内核版本的glibc库构建时，可能会发生这种情况，但通常涉及2.4版本。对于相同系列(2.6)的内核是否有可能得到这样的错误，或者这可能来自其他东西?

另外，我读到这个问题的解决方案是用适当的——enable-kernel= version选项编译的另一个版本的glibc重新构建应用程序。作为一种替代方案，您可以动态地将应用程序与glibc链接以解决问题吗?

谢谢你的帮助。

UPDATE:我知道我的问题可能看起来很模糊，或者已经提到的解决方案之一(动态链接，在另一个[虚拟]系统上构建，重建glibc[考虑到我读到的评论似乎相当棘手])，但我最终寻找的是防止此类问题的方法。

例如，是否有可能找到哪些版本的Linux内核与特定构建的glibc兼容?

UPDATE 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"，它表示最小的内核版本。