SDK_OLDEST_KERNEL vs OLDEST_KERNEL

SDK_OLDEST_KERNEL vs OLDEST_KERNEL

[Martin Jansa]

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

Hi,

is this separate variable working correctly?

It was introduced in:
commit 522ba4c51fff53566678b2689d0d63c393e417b3
Author: Richard Purdie <richard.purdie@linuxfoundation.org>
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,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]

Re: SDK_OLDEST_KERNEL vs OLDEST_KERNEL

[Paul Eggleton]

Hi Martin,

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 <richard.purdie@linuxfoundation.org>
> 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.

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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK_OLDEST_KERNEL vs OLDEST_KERNEL

[Paul Eggleton]

On Thu, 13 Oct 2016 09:38:08 Paul Eggleton wrote:
> 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 <richard.purdie@linuxfoundation.org>
> > 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.
> 
> 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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK_OLDEST_KERNEL vs OLDEST_KERNEL

[Khem Raj]

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

On Oct 13, 2016 5:23 AM, "Paul Eggleton" <paul.eggleton@linux.intel.com>
wrote:
>
> On Thu, 13 Oct 2016 09:38:08 Paul Eggleton wrote:
> > 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 <richard.purdie@linuxfoundation.org>
> > > 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.
> >
> > 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.

For x86/x86_64  2.6.32 would still work which is the most common arch for
sdk host.
>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre

[-- Attachment #2: Type: text/html, Size: 3494 bytes --]

Re: SDK_OLDEST_KERNEL vs OLDEST_KERNEL

[Paul Eggleton]

On Thu, 13 Oct 2016 08:14:07 Khem Raj wrote:
> On Oct 13, 2016 5:23 AM, "Paul Eggleton" <paul.eggleton@linux.intel.com>
> wrote:
> > 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

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: SDK_OLDEST_KERNEL vs OLDEST_KERNEL

[Martin Jansa]

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

On Thu, Oct 13, 2016 at 04:23:21PM +1300, Paul Eggleton wrote:
> On Thu, 13 Oct 2016 09:38:08 Paul Eggleton wrote:
> > 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 <richard.purdie@linuxfoundation.org>
> > > 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.
> > 
> > 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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 169 bytes --]