[OE-core] 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 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.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre