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.pur...@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.



Paul Eggleton
Intel Open Source Technology Centre
Openembedded-core mailing list

Reply via email to