Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: [RFC] Build directory reuse issue - make WORKDIR machine specific?
Date: Mon, 09 Dec 2013 11:30:27 +0000	[thread overview]
Message-ID: <1386588627.25847.77.camel@ted> (raw)

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






             reply	other threads:[~2013-12-09 11:30 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-09 11:30 Richard Purdie [this message]
2013-12-09 11:44 ` [RFC] Build directory reuse issue - make WORKDIR machine specific? Burton, Ross
2013-12-09 12:01   ` Otavio Salvador
2013-12-09 13:43 ` Martin Jansa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1386588627.25847.77.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox