Re: SDK_OLDEST_KERNEL vs OLDEST_KERNEL

[Martin Jansa <martin.jansa@gmail.com>]

[-- 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 --]