1490 2011-09-16 11:33:46 +0000 Failure when adding or modifying a toolchain component with multilibs active 2011-09-21 18:27:58 +0000 1 1 7 Build System, Metadata & Runtime Meta-yocto meta-yocto unspecified x86 Multiple RESOLVED WORKSFORME High major 1.1 1 mark.hatle richard.purdie poky.bs.watcher poky.watcher sgw --- --- --- oldest_to_newest 16271 0 mark.hatle 2011-09-16 11:33:46 +0000 When adding or modifying toolchain components in a multilib configuration, "configure" may fail. I modified eglibc's recipe and told bitbake to build. It noticed the modification and tried to build the new eglibc resulting in: checking how to run the C preprocessor... i586-oemllib32-linux-gcc -E --sysroot=/home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/sysroots/lib32-qemux86-tcbootstrap -m32 configure: error: in`/home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/work/x86-oemllib32-linux/lib32-eglibc-2.13-r15+svnr14157/build-i586-oemllib32-linux': configure: error: C preprocessor "i586-oemllib32-linux-gcc -E --sysroot=/home/mhatle/git/oss/oe-core/build-x86_64/tmp-eglibc/sysroots/lib32-qemux86-tcbootstrap -m32" fails sanity check To reproduce this failure: Configure a system such as: MULTILIB_IMAGE_INSTALL = "lib32-connman-gnome lib32-task-base-3g lib32-task-base-wifi lib32-task-base-bluetooth" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "x86" MACHINE_virtclass-multilib-lib32 = "qemux86" MACHINE = "qemux86_64 build core-image-minimal Then edit the PR in eglibc. build core-image-minimal a second time. An alternative way of causing this failure: configure MACHINE = "qemux86_64" build core-image-minimal edit the conf/local.conf and add the multilib items from above. again attempt to build core-image-minimal it will fail in a similar way. 16282 1 richard.purdie 2011-09-19 00:24:32 +0000 I'm not convinced this MACHINE_<multilib-override> stuff is a good idea at all. Shouldn't we be selecting different tune's instead? 16374 2 richard.purdie 2011-09-21 18:18:08 +0000 I tested this without the MACHINE_<xxx> variable change and was unable to reproduce. I think this is an artifact of specific patch which was rejected and an alternative merged. I'm therefore closing this out unless someone can reproduce this against master. 16375 3 mark.hatle 2011-09-21 18:27:58 +0000 I agree. I have done similar configurations in the past few days and everything appears to be working properly now. I'm not sure what changed.