We have a type of bug where a build directory has configuration changed
halfway through its usage and this breaks other parts of the system. The
one we keep seeing can be seen with this sequence:

MACHINE=qemumips bitbake perl;  
MACHINE=routerstationpro bitbake perl -c populate_sysroot -f; 
MACHINE=routerstationpro bitbake libxml-parser-perl

which results in:

ERROR: QA Issue: package libxml-parser-perl contains bad RPATH 
/media/build1/poky/build/tmp/sysroots/routerstationpro/usr/lib in file 
/media/build1/poky/build/tmp/work/mips32-poky-linux/libxml-parser-perl/2.41-r3/packages-split/libxml-parser-perl/usr/lib/perl/vendor_perl/5.14.3/auto/XML/Parser/Expat/Expat.so

Basically the trouble is the perl workdir has "qemumips" paths in it, we
then switch to routerstationpro and the qemumips ones slip into the
routerstationpro sysroot. The trouble is this kind of corruption can
happen silently and results in very weird and hard to debug errors. In
this case it comes from:

usr/lib/perl/5.14.3/ExtUtils/Liblist/Kid.pm:    push(@libpath, 
"/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-mips-lsb/build/build/tmp/sysroots/qemumips/usr/lib");

which is in the routerstationpro sysroot, therefore the RPATH gets added
when it shouldn't be.

Options to address this as far as I can tell are:

a) Save the machine name during do_configure to WORKDIR and then check
it in subsequent tasks
b) Make WORKDIR be machine specific.


b) looks attractive but could be confusing as we'd no longer have
PACKAGE_ARCH workdirs, they'd all be "machine specific" however they
would still get reused by sstate as they are today. It does however
neatly sidestep the set of issues we're currently seeing.

Thoughts?

Cheers,

Richard




_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to