[OE-core] [RFC] Build directory reuse issue - make WORKDIR machine specific?

[Martin Jansa]

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
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20131209/34470f80/attachment-0002.sig>