[OE-core] SDK_OLDEST_KERNEL vs OLDEST_KERNEL
Martin Jansa
martin.jansa at gmail.com
Thu Oct 13 11:44:05 UTC 2016
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 at 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 at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 163 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161013/fcc323ca/attachment-0002.sig>
More information about the Openembedded-core
mailing list