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.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. > > 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.ja...@gmail.com
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
