Предсказывать "слишком старые" ошибки ядра между версиями ядра 2.6.16 и 2.6.26

Я создаю приложение на машине под управлением Linux (Debian) с ядром 2.6.26-2-amd64, и я хочу запустить это приложение на другой машине под управлением Linux (Suse) с ядром 2.6.16.60-0.21-smp, но я получите ошибку "FATAL: ядро слишком старое".

Я знаю из исследования в Интернете, что это может произойти при создании против библиотеки glibc, которая не была скомпилирована для поддержки старых версий ядра, но обычно это относится к версии 2.4. Можно ли получить такие ошибки для ядра того же ряда (2.6) или это может быть от чего-то еще?

Кроме того, я прочитал, что решение этой проблемы заключается в том, чтобы переустановить приложение на другую версию glibc, скомпилированную с соответствующим параметром --enable-kernel = VERSION. В качестве альтернативы вы можете просто динамически связать свое приложение с glibc, чтобы решить проблему?

Благодарим вас за помощь.

ОБНОВЛЕНИЕ. Я понимаю, что мой вопрос может показаться неопределенным или решен одним из уже упомянутых решений (динамическое связывание, построение на другой [виртуальной] системе, перестроение 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)
[...]

Это объясняет "слишком старую" ошибку. Надеюсь, это поможет другим людям.

Ответ 1