From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFCv1 2/4] core: change host RPATH handling
Date: Wed, 8 Nov 2017 13:30:03 +0100 [thread overview]
Message-ID: <20171108133003.13a24547@windsurf> (raw)
In-Reply-To: <c1b899b3-2b3b-0b35-2f4c-43f4e4935449@mind.be>
Hello,
On Wed, 8 Nov 2017 11:55:19 +0100, Arnout Vandecappelle wrote:
> >>> To me, this sounds very reasonable. What do you think?
> >>
> >> 500 files is not a lot if you include staging as well
> >
> > Why would I include staging? I don't see at all why fixing up RPATH in
> > staging after each package build would be necessary.
>
> The simplest way would be to do find $(HOST_DIR) -type f but that includes staging.
Hum, you didn't reply to my question, which was: "Why would we need to
fixup RPATHs in STAGING_DIR" ?
> >> But $(HOST_DIR)/{bin,sbin,lib} should be enough anyway.
>
> So this is not true, we also need $(HOST_DIR)/$(GNU_TARGET_NAME)/{bin,lib}.
> So then it's perhaps easier to just -prune staging.
Absolutely.
> > Yes, that was my intent. If needed, we could optimize it by only doing
> > the fixup at the end of a host package installation. But since we have
> > a few target packages installing host stuff (toolchain, qt, etc.), it
> > would require them to explicitly state that they need host rpath
> > fixups. Perhaps it's easiest for now to just do the rpath fixup after
> > every package installation.
>
> After every package installation would be better, yes.
ACK.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-11-08 12:30 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-03 16:06 [Buildroot] [RFCv1 0/4] Per-package SDK and target directories Thomas Petazzoni
2017-11-03 16:06 ` [Buildroot] [RFCv1 1/4] pkgconf: use relative path to STAGING_DIR instead of absolute path Thomas Petazzoni
2017-11-07 21:05 ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 2/4] core: change host RPATH handling Thomas Petazzoni
2017-11-05 8:57 ` Yann E. MORIN
2017-11-05 14:44 ` Thomas Petazzoni
2017-11-05 14:48 ` Arnout Vandecappelle
2017-11-07 22:41 ` Thomas Petazzoni
2017-11-07 23:50 ` Arnout Vandecappelle
2017-11-08 8:55 ` Thomas Petazzoni
2017-11-08 10:55 ` Arnout Vandecappelle
2017-11-08 12:30 ` Thomas Petazzoni [this message]
2017-11-08 12:38 ` Arnout Vandecappelle
2017-11-07 21:15 ` Arnout Vandecappelle
2017-11-07 21:22 ` Thomas Petazzoni
2017-11-07 23:45 ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 3/4] toolchain: post-pone evaluation of TOOLCHAIN_EXTERNAL_BIN Thomas Petazzoni
2017-11-07 21:23 ` Arnout Vandecappelle
2017-11-07 21:33 ` Thomas Petazzoni
2017-11-07 23:49 ` Arnout Vandecappelle
2017-11-03 16:06 ` [Buildroot] [RFCv1 4/4] core: implement per-package SDK and target Thomas Petazzoni
2017-11-07 22:50 ` Arnout Vandecappelle
2017-11-07 23:11 ` Thomas Petazzoni
2017-11-07 23:57 ` Arnout Vandecappelle
2017-11-24 14:49 ` Thomas Petazzoni
2017-11-24 14:43 ` Thomas Petazzoni
2017-11-25 17:30 ` Arnout Vandecappelle
2017-11-25 20:01 ` Thomas Petazzoni
2017-11-27 14:23 ` Yann E. MORIN
2017-11-07 23:21 ` [Buildroot] [RFCv1 0/4] Per-package SDK and target directories Arnout Vandecappelle
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=20171108133003.13a24547@windsurf \
--to=thomas.petazzoni@free-electrons.com \
--cc=buildroot@busybox.net \
/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.