Bug 3312

Summary:	glib-2.0 fails to build in a multimachine tmpdir
Product:	[Build System, Metadata & Runtime] OE-Core	Reporter:	Khem Raj <raj.khem>
Component:	core	Assignee:	Saul Wold <sgw>
Status:	RESOLVED NOTABUG	QA Contact:
Severity:	normal
Priority:	Medium	CC:	corneliux.stoicescu, meta.mr.watcher, meta.watcher, richard.purdie
Version:	1.3
Target Milestone:	1.4
Hardware:	x86
OS:	x86_64
Whiteboard:
OS type for building Yocto:	---	Type of Regression:	---
Verified:		Documentation change:	---

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 :)