3312 2012-10-19 17:38:20 +0000 glib-2.0 fails to build in a multimachine tmpdir 2012-10-31 09:52:43 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 1.3 x86 x86_64 RESOLVED NOTABUG Medium normal 1.4 1 raj.khem sgw corneliux.stoicescu meta.mr.watcher meta.watcher richard.purdie --- --- --- oldest_to_newest 26772 0 raj.khem 2012-10-19 17:38:20 +0000 $ 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. 26776 1 sgw 2012-10-19 22:52:16 +0000 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? 26777 2 raj.khem 2012-10-19 23:40:35 +0000 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. 26778 3 raj.khem 2012-10-20 04:16:34 +0000 and I have multilib enabled too. 26868 4 richard.purdie 2012-10-24 20:41:57 +0000 I also had a try at reproducing this with poky master but couldn't do so. We need more information about how to reproduce... 27005 5 corneliux.stoicescu 2012-10-29 15:30:44 +0000 It worked for me in a clean build directory. Branch: master Commit: 93c04c16e45a3c8f60f8ffc0b26a78c24bda71da 27087 6 raj.khem 2012-10-31 05:09:37 +0000 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. 27097 7 corneliux.stoicescu 2012-10-31 09:52:43 +0000 What is the status of this bug? Still not a bug? If not, is there a patch out? thank you :)