From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath
Date: Sun, 6 May 2018 22:26:41 +0200 [thread overview]
Message-ID: <20180506222641.6c1d4dc7@windsurf> (raw)
In-Reply-To: <876040pmgy.fsf@dell.be.48ers.dk>
Hello,
On Sun, 06 May 2018 22:18:05 +0200, Peter Korsgaard wrote:
> > binutils installs its binaries both as bin/<tuple>-<tool> and as
> > <tuple>/bin/<tool>, and hardlinks are used to reduce disk space
> > consumption. This causes a problem for host-binutils with our rpath
> > fixing logic done by "make sdk".
>
> > Indeed, the fix-rpath script starts by fixing up the rpath of
> > bin/<tuple>-<tool>, and sets the RPATH to $ORIGIN/../lib/. Then
> > fix-rpath moves on to <tuple>/bin/<tool>, and doesn't find the library
> > the tool depends on, and clears the RPATH. The result is that the
> > binutils tool are not usable.
>
> > Note that this is only visible currently on the ARC architecture,
> > because on this architecture, binutils is fetched from git, which
> > causes host-flex to be built, and some binutils tools to use the libfl
> > shared library. Therefore, the binutils tools don't use just the
> > standard C library (which is provided by the system) but also libfl
> > from $(HOST_DIR)/lib, and therefore if the RPATH isn't set correctly,
> > those tools don't work properly.
>
> > In order to address this, this comit adds a post-install hook to
> > host-binutils that replaces those hard links by symbolic links. It is
> > worth mentioning that library loading and RPATH usage occurs *after*
> > resolving the symbolic links, which makes this solution work.
>
> > Fixes:
>
> > http://autobuild.buildroot.net/results/b2562b05d397d4e1ffe0f8d2f4ce4c84ab6feae1/
>
> > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
>
> Committed, thanks.
Hum, I think Yann had some second thoughts about this patch. He was not
able to reproduce the binutils tools being linked to libfl, and it also
isn't clear why they get linked to libfl in the first place.
So, the problem is real, this patch works around it, but there's still
a bit of mystery.
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2018-05-06 20:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-22 12:23 [Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath Thomas Petazzoni
2018-04-23 9:22 ` Yann E. MORIN
2018-04-23 13:04 ` Thomas Petazzoni
2018-04-23 13:42 ` Yann E. MORIN
2018-05-06 20:18 ` Peter Korsgaard
2018-05-06 20:26 ` Thomas Petazzoni [this message]
2018-05-06 21:29 ` Yann E. MORIN
2018-05-24 21:05 ` Peter Korsgaard
2018-05-28 20:07 ` Yann E. MORIN
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=20180506222641.6c1d4dc7@windsurf \
--to=thomas.petazzoni@bootlin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox