On 11/10/2015 12:27 AM, Burton, Ross wrote:
On 4 November 2015 at 13:58, Robert Yang <[email protected] <mailto:[email protected]>> wrote: The arm toolchain has a "-gnueabi" suffix, but aarch64 doesn't, this makes multilib sdk doesn't work, for example: MACHINE = qemuarm64 require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon" $ bitbake core-image-minimal -cpopulate_sdk Then extract SDK, the environment-setup-armv7a-vfp-neon-pokymllib32-linux-gnueabi doesn't work since: * The CC is arm-pokymllib32-linux-gnueabi-gcc which doesn't exist, the patch for cross-canadian.bbclass fixes problem. * Need aarch64-poky-linux/usr/lib/arm-poky-linux-linux-gnueabi which doesn't exist, the patch for libgcc-common.inc fixes the problem. [YOCTO #8616] This breaks the allarch sstate sanity test on the autobuilder which verifies that allarch recipes don't have different hashes for a no-op change to the machine.
Hi Ross, After more investigations, the different between: MACHINE=qemux86 bitbake -Snone meta-toolchain MACHINE=qemuarm bitbake -Snone meta-toolchain is do_extra_symlinks' checksum, there is an ABIEXTENSION for nativesdk-libgcc-initial when qemuarm (eabi), and no "eabi" when qemux86. But as the commit said, the "eabi" is a must for qemuarm since its compiler arm-pokymllib32-linux-gnueabi-gcc contains eabi, otherwise it doesn't work. Maybe let the test case don't compare between qemuarm and qemux86 since arm is special ? Or do you have any other suggestions, please ? // Robert
https://autobuilder.yoctoproject.org/main/builders/nightly-oe-selftest/builds/242/steps/Running%20oe-selftest/logs/stdio Ross
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
