All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Conroy <Chris.Conroy@hillcrestlabs.com>
To: openembedded-devel@lists.openembedded.org
Cc: Phil Black <Phil.Black@hillcrestlabs.com>
Subject: Packaged-staging and RPATH with native/cross/sdk
Date: Thu, 30 Jul 2009 17:34:31 -0400	[thread overview]
Message-ID: <1248989671.3629.1358.camel@conroy-linux> (raw)

I'm trying to use packaged-staging to set up a sane prebuilt toolchain
environment to share with other developers. I view packaged-staging as a
promising route of creating a "Stage 3" version of OE (to use some
Gentoo parlance). While building the toolchain isn't all that painful,
even on a decent system it can add 1-2 hours to the build process, and
every individual developer needs to redo the toolchain and base
libraries for every feature branch. This is all needlessly wasted time
since they're all ultimately building the same things if on the same
arch.

Packaged-staging seems to give me everything we need in order to
accomplish this except for the way RPATH is handled. This is a known
issue which is worked around in packaged-staging with the following
snippet:

    # These classes encode staging paths into the binary data so can
only be
    # reused if the path doesn't change/
    if bb.data.inherits_class('native', d) or
bb.data.inherits_class('cross', d) or bb.data.inherits_class('sdk', d):
        path = bb.data.getVar('PSTAGE_PKGPATH', d, 1)
        path = path + bb.data.getVar('TMPDIR', d, 1).replace('/', '-')
        bb.data.setVar('PSTAGE_PKGPATH', path, d)


I'm currently toying with changing the references to rpath in
bitbake.conf to use $ORIGIN rather than an absolute path, but perhaps
some of you have better ideas. (I have a feeling this is going to run
into some nasty edge cases).

(The other, less elegant idea I am toying with is: modify the
packaged-staging install to hotfix the binary data to point at the new
install location, but this seems uglier and possibly harder to
implement)

If this special case is taken away, then distributions can much more
easily share a prebuilt toolchain and set of system libraries for
potential developers or with a team. It also gives us some other nice
properties (e.g. you want to relocate your OE directory because your
disk is filling up, but you don't want to have to do a full rebuild)


Thoughts, suggestions, reasons this won't ever possibly work?

--Chris Conroy



             reply	other threads:[~2009-07-30 21:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-30 21:34 Chris Conroy [this message]
2009-07-30 22:16 ` Packaged-staging and RPATH with native/cross/sdk Chris Larson
2009-07-31 15:45   ` Tom Rini
2009-07-31 14:50 ` Richard Purdie

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=1248989671.3629.1358.camel@conroy-linux \
    --to=chris.conroy@hillcrestlabs.com \
    --cc=Phil.Black@hillcrestlabs.com \
    --cc=openembedded-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.