On Mon, Dec 09, 2013 at 11:30:27AM +0000, Richard Purdie wrote: > 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.
I guess I haven't seen this issue because I'm using rm_work. Stamps already gone after "bitbake perl" so running it for routerstationpro reuses it from sstate just like it would for MACHINE_ARCh WORKDIR, right? Can we do something like that as c) solution? What would happen in a) when the check detects different MACHINE? - fail with good error message? - automagically "fix" workdir content like sstate_installpkg does? > 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 -- Martin 'JaMa' Jansa jabber: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
