From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [RFCv1 2/4] core: change host RPATH handling
Date: Tue, 7 Nov 2017 22:22:59 +0100 [thread overview]
Message-ID: <20171107222259.4ec2548c@windsurf> (raw)
In-Reply-To: <ca5edb67-da78-bf4c-1578-c897a26218c6@mind.be>
Hello,
On Tue, 7 Nov 2017 22:15:38 +0100, Arnout Vandecappelle wrote:
> > An alternative strategy would have been to keep the
> > -Wl,-rpath,$(HOST_DIR) flag, and therefore the absolute RPATH in the
> > host binaries, and fix such RPATH at the end of the build of every
> > package. However, that would require calling fix-rpath after the
> > installation of every package, which is a bit expensive.
>
> As discussed, this would be the preferred approach after all.
Yes, agreed.
> > This change is independent from the per-package SDK functionality, and
> > could be applied separately.
>
> Shouldn't this type of comment be below the --- ?
Well, it's not really that I expected the v1 of the patches to be
merged :-)
> > @@ -89,7 +89,8 @@ main() {
> > cp "${PATCHELF}" "${PATCHELF}.__to_be_patched"
> >
> > # we always want $ORIGIN-based rpaths to make it relocatable.
> > - sanitize_extra_args+=( "--relative-to-file" )
> > + sanitize_args+=( "--set-rpath" )
> > + sanitize_args+=( "\$ORIGIN/../lib" )
>
> One advantage of --make-rpath-relative over --set-rpath is that the former will
> also remove rpaths that are not needed (which I guess is often the case for host
> tools).
Well, --set-rpath sets the RPATH, so I believe it entirely removes any
existing RPATH and replaces them all by just $ORIGIN/../lib. So I don't
see how it could be more "efficient", since we're down to a single
RPATH, which is the only rpath that is needed.
Perhaps the only problem that I can think of is if some host binaries
do have libraries installed in non-standard locations, and really need
a custom absolute RPATH such
as /home/foo/buildroot/output/per-package/host/lib/baz/ to be turned
into $ORIGIN/../lib/baz/. However, I don't think we have such
non-standard library locations for host packages, so I simply ignored
this possible problem for now. It is a problem that can be fixed later
on if needed by adjusting the host rpath mangling logic.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
next prev parent reply other threads:[~2017-11-07 21:22 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
2017-11-08 12:38 ` Arnout Vandecappelle
2017-11-07 21:15 ` Arnout Vandecappelle
2017-11-07 21:22 ` Thomas Petazzoni [this message]
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=20171107222259.4ec2548c@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.