Bug 3312 - glib-2.0 fails to build in a multimachine tmpdir
Summary: glib-2.0 fails to build in a multimachine tmpdir
Status: RESOLVED NOTABUG
Alias: None
Product: OE-Core
Classification: Build System, Metadata & Runtime
Component: core (show other bugs)
Version: 1.3
Hardware: x86 x86_64
: Medium normal
Target Milestone: 1.4
Assignee: Saul Wold
QA Contact:
URL:
Whiteboard:
Depends on:
Blocks:
 
Reported: 2012-10-19 17:38 UTC by Khem Raj
Modified: 2012-10-31 09:52 UTC (History)
4 users (show)

See Also:
OS type for building Yocto: ---
Type of Regression: ---
Verified:
Documentation change: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Khem Raj 2012-10-19 17:38:20 UTC 
$ MACHINE=qemux86-64 bitbake glib-2.0; MACHINE=sugarbay bitbake glib-2.0

would fail when building for second machine with QA errors like


| /work/yocto/poky/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.7.2/ld: cannot find /lib/libpthread.so.0
| /work/yocto/poky/build/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.7.2/ld: cannot find /usr/lib/libpthread_nonshared.a
| collect2: error: ld returned 1 exit status
| make[6]: *** [libresourceplugin.la] Error 1
| make[6]: *** Waiting for unfinished jobs....
| make[6]: Leaving directory `/work/yocto/poky/build/tmp-eglibc/work/x86_64-poky-linux/glib-2.0-1_2.32.4-r6/glib-2.32.4/gio/tests'
| make[5]: *** [all-recursive] Error 1


order of machines does not matter the second one will always fail.
Comment 1 Saul Wold 2012-10-19 22:52:16 UTC 
I could not reproduce this, I tried with both Danny and master, can you give me any additional clues?  I also tried from a clean (no sstate) to a second build with sstate and still no failure.

Do you have local.conf changes?
Comment 2 Khem Raj 2012-10-19 23:40:35 UTC 
hmmm my setup does have changes. I will try it with pure poky and see if I can reproduce. But I delete my tmpdir and then execute both machine builds without deleting the tmpdir. Actually try to bake core-image-lab and see if you can reproduce it.
Comment 3 Khem Raj 2012-10-20 04:16:34 UTC 
and I have multilib enabled too.
Comment 4 Richard Purdie 2012-10-24 20:41:57 UTC 
I also had a try at reproducing this with poky master but couldn't do so. We need more information about how to reproduce...
Comment 5 Stoicescu Cornel 2012-10-29 15:30:44 UTC 
It worked for me in a clean build directory.

Branch: master
Commit: 93c04c16e45a3c8f60f8ffc0b26a78c24bda71da
Comment 6 Khem Raj 2012-10-31 05:09:37 UTC 
OK finally figured it out thanks to bitbake-diffsigs found out that machineA (custom BSP) enabled multilib but when using default BSPs from meta-intel e.g. sugarbay, multilib was disabled, and for x86_64 baselib changes from /lib to /lib64 if multilib is enabled. This caused a good amount of sstate signatures to changes and essentially it was rebuilding lot of packages into /lib instead of /lib64 

once I fixed the multilib to be uniform, I got past this error.

Thanks for spending time to help me out.
Comment 7 Stoicescu Cornel 2012-10-31 09:52:43 UTC 
What is the status of this bug? Still not a bug? If not, is there a patch out? thank you :)