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.
I'm not convinced this MACHINE_<multilib-override> stuff is a good idea at all. Shouldn't we be selecting different tune's instead?
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.
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.