[OE-core] [RFC] glibc kernel version

[Jonathan David]

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

--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -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' \