Bug 1490

Summary: Failure when adding or modifying a toolchain component with multilibs active
Product: [Build System, Metadata & Runtime] Meta-yocto Reporter: Mark Hatle <mark.hatle>
Component: meta-yoctoAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED WORKSFORME QA Contact:
Severity: major    
Priority: High CC: poky.bs.watcher, poky.watcher, sgw
Version: unspecified   
Target Milestone: 1.1   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Mark Hatle 2011-09-16 11:33:46 UTC 
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.
Comment 1 Richard Purdie 2011-09-19 00:24:32 UTC 
I'm not convinced this MACHINE_<multilib-override> stuff is a good idea at all. Shouldn't we be selecting different tune's instead?
Comment 2 Richard Purdie 2011-09-21 18:18:08 UTC 
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.
Comment 3 Mark Hatle 2011-09-21 18:27:58 UTC 
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.