[RFC] glibc kernel version

[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' \

Re: [RFC] glibc kernel version

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]


> On Nov 24, 2015, at 9:29 AM, Jonathan David <jonathan.david@ni.com> wrote:
> 
> 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?

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.

> 
> 
> 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' \
> 
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]