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

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

[Richard Purdie]

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

Re: [RFC] Build directory reuse issue - make WORKDIR machine specific?

[Burton, Ross]

On 9 December 2013 11:30, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> 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.

As someone who often switches between mostly-compatible machines
(qemux86/qemux86-64/genericx86/nuc) I'm often hitting problems like
this.  Most recently libproxy was using a sysroot that didn't exist,
which prompted my cmake patch.

Presumably the change would replace the package-architecture element
in the path with the machine name.  Seems reasonable to me: a more
logical layout of files without any meaningful impact to performance.

Ross

Re: [RFC] Build directory reuse issue - make WORKDIR machine specific?

[Otavio Salvador]

On Mon, Dec 9, 2013 at 9:44 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 9 December 2013 11:30, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>> 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.
>
> As someone who often switches between mostly-compatible machines
> (qemux86/qemux86-64/genericx86/nuc) I'm often hitting problems like
> this.  Most recently libproxy was using a sysroot that didn't exist,
> which prompted my cmake patch.
>
> Presumably the change would replace the package-architecture element
> in the path with the machine name.  Seems reasonable to me: a more
> logical layout of files without any meaningful impact to performance.

I agree with Ross here.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [RFC] Build directory reuse issue - make WORKDIR machine specific?

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]

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

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]