SDK_OLDEST_KERNEL vs OLDEST_KERNEL

DISCUSSION Martin Jansa 3 participants 6 messages Oct 12, 2016 – Oct 13, 2016

lore

Share & tools

lore

Martin Jansa

author

2016-10-12 13:26 UTC #0 lore raw

Hi,

is this separate variable working correctly?

It was introduced in:
commit 522ba4c51fff53566678b2689d0d63c393e417b3

Author: Richard Purdie <[email protected]>
Date:   Fri Sep 11 13:25:46 2015 +0100

populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues

aarch64 sets OLDEST_KERNEL to 3.14. This stops the aarch64 SDK installing on anything with an older kernel which is clearly incorrect.

I attempted to extract the correct non-overridden version from the data store but it proved problematic and I was running into data store issues. Those are a separate problem but there isn't time to fix this right now.

Instead just code the SDK kernel version separately to work around this for now (and fix the autobuilder tests and SDK usage).

But when I'm using:
OLDEST_KERNEL = "3.2" (default)
SDK_OLDEST_KERNEL = "2.6.32"
because we would like to use SDK on host with older kernel, then SDK_OLDEST_KERNEL helped to bypass the uname check in environment-setup script, but then gcc cannot be used, because it fails immediately with:

FATAL: kernel too old

So I'm not sure what this variable are trying to achieve, maybe autobuilder tests were only testing setup script and not the actual $CC?

The other option is that it works only when sdk toolchain is built with default OLDEST_KERNEL (which is lower than OLDEST_KERNEL_aarch64) and only target bits use OLDEST_KERNEL_aarch64, but those aren't executed on host using SDK.

Regards,

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]

Paul Eggleton

2016-10-12 20:38 UTC #1 lore raw

Hi Martin,

Quoted 28 lines · On Wed, 12 Oct 2016 15:26:15 Martin Jansa wrote:

is this separate variable working correctly?
It was introduced in:
commit 522ba4c51fff53566678b2689d0d63c393e417b3
Author: Richard Purdie <[email protected]>
Date:   Fri Sep 11 13:25:46 2015 +0100
populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues
aarch64 sets OLDEST_KERNEL to 3.14. This stops the aarch64 SDK
installing on anything with an older kernel which is clearly incorrect.
I attempted to extract the correct non-overridden version from the data
store but it proved problematic and I was running into data store issues. Those are a separate problem but there isn't time to fix this right now.
Instead just code the SDK kernel version separately to work around this
for now (and fix the autobuilder tests and SDK usage).
But when I'm using:
OLDEST_KERNEL = "3.2" (default)
SDK_OLDEST_KERNEL = "2.6.32"
because we would like to use SDK on host with older kernel, then SDK_OLDEST_KERNEL helped to bypass the uname check in environment-setup script, but then gcc cannot be used, because it fails immediately with:
FATAL: kernel too old

Quoted 7 lines

So I'm not sure what this variable are trying to achieve, maybe autobuilder tests were only testing setup script and not the actual $CC?
The other option is that it works only when sdk toolchain is built with default OLDEST_KERNEL (which is lower than OLDEST_KERNEL_aarch64) and only target bits use OLDEST_KERNEL_aarch64, but those aren't executed on host using SDK.

I'm not sure how this ever could have worked, since it doesn't enter into the nativesdk-glibc configuration. It seems to me that the glibc recipe needs to be using SDK_OLDEST_KERNEL in place of OLDEST_KERNEL for class-nativesdk.

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Paul Eggleton

2016-10-13 03:23 UTC #2 lore raw

Quoted 43 lines · On Thu, 13 Oct 2016 09:38:08 Paul Eggleton wrote:

Quoted 33 lines · On Wed, 12 Oct 2016 15:26:15 Martin Jansa wrote:
is this separate variable working correctly?
It was introduced in:
commit 522ba4c51fff53566678b2689d0d63c393e417b3
Author: Richard Purdie <[email protected]>
Date:   Fri Sep 11 13:25:46 2015 +0100
populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues
aarch64 sets OLDEST_KERNEL to 3.14. This stops the aarch64 SDK
installing on anything with an older kernel which is clearly incorrect.
I attempted to extract the correct non-overridden version from the data
store but it proved problematic and I was running into data store issues. Those are a separate problem but there isn't time to fix this right now.
Instead just code the SDK kernel version separately to work around this
for now (and fix the autobuilder tests and SDK usage).
But when I'm using:
OLDEST_KERNEL = "3.2" (default)
SDK_OLDEST_KERNEL = "2.6.32"
because we would like to use SDK on host with older kernel, then SDK_OLDEST_KERNEL helped to bypass the uname check in environment-setup script, but then gcc cannot be used, because it fails immediately with:
FATAL: kernel too old
Quoted 8 lines
So I'm not sure what this variable are trying to achieve, maybe autobuilder
tests were only testing setup script and not the actual $CC?
The other option is that it works only when sdk toolchain is built with default OLDEST_KERNEL (which is lower than OLDEST_KERNEL_aarch64) and only target bits use OLDEST_KERNEL_aarch64, but those aren't executed on host using SDK.

Quoted 4 lines

I'm not sure how this ever could have worked, since it doesn't enter into the nativesdk-glibc configuration. It seems to me that the glibc recipe needs to be using SDK_OLDEST_KERNEL in place of OLDEST_KERNEL for class-nativesdk.

Thinking about it - even if that were fixed, would setting it to 2.6.32 actually work on master? We are now using glibc 2.24 and that requires a minimum kernel version of 3.2.0.

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Khem Raj

2016-10-13 06:14 UTC #3 lore raw

Quoted 10 lines · Paul Eggleton

Quoted 8 lines · On Thu, 13 Oct 2016 09:38:08 Paul Eggleton wrote:
Quoted 7 lines · On Wed, 12 Oct 2016 15:26:15 Martin Jansa wrote:
is this separate variable working correctly?
It was introduced in:
commit 522ba4c51fff53566678b2689d0d63c393e417b3
Author: Richard Purdie <[email protected]>
Date:   Fri Sep 11 13:25:46 2015 +0100

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues
aarch64 sets OLDEST_KERNEL to 3.14. This stops the aarch64 SDK
installing on anything with an older kernel which is clearly

incorrect.

Quoted 5 lines

Quoted 5 lines
Quoted 5 lines
I attempted to extract the correct non-overridden version from the data
store but it proved problematic and I was running into data store

issues.

Quoted 1 line

Quoted 1 line
Quoted 1 line
Those are a separate problem but there isn't time to fix this right

now.

Quoted 11 lines

Quoted 11 lines
Quoted 11 lines
Instead just code the SDK kernel version separately to work around this
for now (and fix the autobuilder tests and SDK usage).
But when I'm using:
OLDEST_KERNEL = "3.2" (default)
SDK_OLDEST_KERNEL = "2.6.32"
because we would like to use SDK on host with older kernel, then SDK_OLDEST_KERNEL helped to bypass the uname check in

environment-setup

Quoted 1 line

Quoted 1 line
Quoted 1 line
script, but then gcc cannot be used, because it fails immediately

with:

Quoted 8 lines

Quoted 8 lines
Quoted 8 lines
FATAL: kernel too old
So I'm not sure what this variable are trying to achieve, maybe autobuilder
tests were only testing setup script and not the actual $CC?
The other option is that it works only when sdk toolchain is built

with

Quoted 1 line

Quoted 1 line
Quoted 1 line
default OLDEST_KERNEL (which is lower than OLDEST_KERNEL_aarch64) and

only

Quoted 1 line

Quoted 1 line
Quoted 1 line
target bits use OLDEST_KERNEL_aarch64, but those aren't executed on

host

Quoted 3 lines

Quoted 3 lines
Quoted 1 line
using SDK.
I'm not sure how this ever could have worked, since it doesn't enter

into

Quoted 7 lines

Quoted 3 lines
the nativesdk-glibc configuration. It seems to me that the glibc recipe needs to be using SDK_OLDEST_KERNEL in place of OLDEST_KERNEL for class-nativesdk.
Thinking about it - even if that were fixed, would setting it to 2.6.32 actually work on master? We are now using glibc 2.24 and that requires a minimum kernel version of 3.2.0.

For x86/x86_64 2.6.32 would still work which is the most common arch for sdk host.

Quoted 8 lines

Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre

Paul Eggleton

2016-10-13 06:25 UTC #4 lore raw

Quoted 8 lines · On Thu, 13 Oct 2016 08:14:07 Khem Raj wrote:

Quoted 3 lines · Paul Eggleton
Thinking about it - even if that were fixed, would setting it to 2.6.32 actually work on master? We are now using glibc 2.24 and that requires a minimum kernel version of 3.2.0.
For x86/x86_64 2.6.32 would still work which is the most common arch for sdk host.

Ah, I see - that exception was not mentioned in the commit message. I see it is in the glibc release notes though.

Cheers,
Paul

Signature · 2 lines

Paul Eggleton
Intel Open Source Technology Centre

Martin Jansa

author

2016-10-13 11:44 UTC #5 lore raw

In reply to Paul Eggleton

Quoted 44 lines · Paul Eggleton

Quoted 43 lines · On Thu, 13 Oct 2016 09:38:08 Paul Eggleton wrote:
Quoted 41 lines · On Wed, 12 Oct 2016 15:26:15 Martin Jansa wrote:
is this separate variable working correctly?
It was introduced in:
commit 522ba4c51fff53566678b2689d0d63c393e417b3
Author: Richard Purdie <[email protected]>
Date:   Fri Sep 11 13:25:46 2015 +0100
populate_sdk_base: Fix aarch64 OLDEST_KERNEL sdk issues
aarch64 sets OLDEST_KERNEL to 3.14. This stops the aarch64 SDK
installing on anything with an older kernel which is clearly incorrect.
I attempted to extract the correct non-overridden version from the data
store but it proved problematic and I was running into data store issues. Those are a separate problem but there isn't time to fix this right now.
Instead just code the SDK kernel version separately to work around this
for now (and fix the autobuilder tests and SDK usage).
But when I'm using:
OLDEST_KERNEL = "3.2" (default)
SDK_OLDEST_KERNEL = "2.6.32"
because we would like to use SDK on host with older kernel, then SDK_OLDEST_KERNEL helped to bypass the uname check in environment-setup script, but then gcc cannot be used, because it fails immediately with:
FATAL: kernel too old
So I'm not sure what this variable are trying to achieve, maybe autobuilder
tests were only testing setup script and not the actual $CC?
The other option is that it works only when sdk toolchain is built with default OLDEST_KERNEL (which is lower than OLDEST_KERNEL_aarch64) and only target bits use OLDEST_KERNEL_aarch64, but those aren't executed on host using SDK.

Quoted 8 lines

Quoted 4 lines
I'm not sure how this ever could have worked, since it doesn't enter into the nativesdk-glibc configuration. It seems to me that the glibc recipe needs to be using SDK_OLDEST_KERNEL in place of OLDEST_KERNEL for class-nativesdk.
Thinking about it - even if that were fixed, would setting it to 2.6.32 actually work on master? We are now using glibc 2.24 and that requires a minimum kernel version of 3.2.0.

I think it might work in the "special" case RP mentioned in commit message and I've tried to describe (I admit quite badly) in my e-mail).

With qemuarm64 I can see from bitbake -e:

OE qemuarm64@ ~/build/oe-core $ grep ^OLDEST_KERNEL= env.*glibc* env.glibc:OLDEST_KERNEL="3.14" env.nativesdk-glibc:OLDEST_KERNEL="3.2.0"

Because the nativesdk-glibc doesn't use the aarch64 OVERRIDE

OE qemuarm64@ ~/build/oe-core $ grep ^OVERRIDES= env.*glibc* env.glibc:OVERRIDES="linux:aarch64:build-linux:pn-glibc:qemuall:qemuarm64:aarch64:nodistro:class-target:forcevariable:libc-glibc" env.nativesdk-glibc:OVERRIDES="linux:x86-64:build-linux:pn-nativesdk-glibc::nodistro:class-nativesdk:forcevariable:libc-glibc:virtclass-nativesdk"

so it's using "default" OLDEST_KERNEL

meta/conf/bitbake.conf:OLDEST_KERNEL = "3.2.0" meta/conf/bitbake.conf:OLDEST_KERNEL_aarch64 = "3.14"

The actual SDK (e.g. meta-toolchain) on the other hand is built with aarch64 in OVERRIDES, so 3.14 made it into the setup environment script even when the glibc included there was built against 3.2.0

OE qemuarm64@ ~/build/oe-core $ grep ^OVERRIDES= env.meta-toolchain OVERRIDES="linux:aarch64:build-linux:pn-meta-toolchain:qemuall:qemuarm64:aarch64:nodistro:class-target:forcevariable:libc-glibc"

So this might be useful for cases where target specific OLDEST_KERNEL is higher than the OLDEST_KERNEL used by nativesdk-glibc, but in my case it isn't enough and I had to lower the kernel version in both (which now I'm testing to see if Khem's and glibc's commit message was right about the x86/x86_64 compatibility - I've already verified that building arm image with 2.6.32 OLDEST_KERNEL causes postinst in do_rootfs to fail, I'm waiting for local build to finish to see the actual error.

Next step is to see if arm binaries built with 2.6.32 nativesdk-glibc (on x86 host) work in arm image built with 3.2.0 glibc - this wasn't clear to me from the commit message.

Thanks

Signature · 1 line

Martin 'JaMa' Jansa     jabber: [email protected]