glibc kernel version

The change below only replaces the kernel version checked by the shar
file, so that machines running on the 2.6 kernel can unpack an SDK
archive; however, the SDK will be unusable if the bundled glibc requires a later kernel than what is installed. glibc's minimal kernel version is determined by OLDEST_KERNEL, which from testing does not appear to be influenced by SDK_OLDEST_KERNEL.

For example, setting OLDEST_KERNEL=3.14 and SDK_OLDEST_KERNEL=2.6 still results in an unusable SDK on systems running [2.6, 3.14) kernels.

Is this a problem that many can expect to encounter, or is bumping the version of glibc beyond 2.6 uncommon?

commit: 522ba4c51fff53566678b2689d0d63c393e417b3
populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues

@@ -81,6 +81,11 @@ python write_host_sdk_manifest () {

POPULATE_SDK_POST_TARGET_COMMAND_append = " write_target_sdk_manifest ; " POPULATE_SDK_POST_HOST_COMMAND_append = " write_host_sdk_manifest; "

+# Some archs override this, we need the nativesdk version +# turns out this is hard to get from the datastore due to TRANSLATED_TARGET_ARCH
+# manipulation.
+SDK_OLDEST_KERNEL = "2.6.32"
+
fakeroot python do_populate_sdk() {
from oe.sdk import populate_sdk
from oe.manifest import create_manifest, Manifest
@@ -156,7 +161,7 @@ EOF
sed -i -e 's#@SDK_ARCH@#${SDK_ARCH}#g' \
-e 's#@SDKPATH@#${SDKPATH}#g' \
-e 's#@SDKEXTPATH@#${SDKEXTPATH}#g' \
- -e 's#@OLDEST_KERNEL@#${OLDEST_KERNEL}#g' \
+ -e 's#@OLDEST_KERNEL@#${SDK_OLDEST_KERNEL}#g' \
-e 's#@REAL_MULTIMACH_TARGET_SYS@#${REAL_MULTIMACH_TARGET_SYS}#g' \
-e 's#@SDK_TITLE@#${SDK_TITLE}#g' \
-e 's#@SDK_VERSION@#${SDK_VERSION}#g' \

We need to compile nativesdk components as well as nativesdk-glibc using this defined to 2.6.32 as well. otherwise it will have wrong assumptions about system calls available to it during build ( 3.14 ) vs at runtime ( 2.6.32 ) and many nativesdk programs could fail to run properly. Please note that 2.22 needs 2.6.32 can’t go below that.