[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Thomas Petazzoni]

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>
---
 package/binutils/binutils.mk | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
index 13cd02b491..b24e4334c2 100644
--- a/package/binutils/binutils.mk
+++ b/package/binutils/binutils.mk
@@ -130,5 +130,17 @@ ifeq ($(BR2_BINUTILS_ENABLE_LTO),y)
 HOST_BINUTILS_CONF_OPTS += --enable-plugins --enable-lto
 endif
 
+# Hardlinks between binaries in different directories cause a problem
+# with rpath fixup, so we de-hardlink those binaries, and replace them
+# with symbolic links.
+BINUTILS_TOOLS = ar as ld ld.bfd nm objcopy objdump ranlib readelf strip
+define HOST_BINUTILS_FIXUP_HARDLINKS
+	$(foreach tool,$(BINUTILS_TOOLS),\
+		rm -f $(HOST_DIR)/$(GNU_TARGET_NAME)/bin/$(tool) ; \
+		ln -s ../../bin/$(GNU_TARGET_NAME)-$(tool) $(HOST_DIR)/$(GNU_TARGET_NAME)/bin/$(tool)
+	)
+endef
+HOST_BINUTILS_POST_INSTALL_HOOKS += HOST_BINUTILS_FIXUP_HARDLINKS
+
 $(eval $(autotools-package))
 $(eval $(host-autotools-package))
-- 
2.14.3

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Yann E. MORIN]

Thomas, All,

On 2018-04-22 14:23 +0200, Thomas Petazzoni spake thusly:
> 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.

So I wanted to test this, and it does what's on the can.

However, I wanted to reproduce the build failures, and here, with
current master, so I built a toolchain with buildroot [0], but none
of binutils programs is linked with libfl:

    $ for i in host/arc-buildroot-linux-uclibc/bin/*; do
        readelf -d "${i}" |grep NEEDED
    done |sort -u
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]

I checked, and I don't have libfl on my system, neither static not
shared, so it cant even have picked the static one from my system.

And indeed, libnl can build:

    checking the archiver (/home/ymorin/dev/buildroot/O/host/bin/arc-buildroot-linux-uclibc-ar)interface... ar

So, I don't see the point...

[0] with this defconfig:
BR2_arcle=y
BR2_archs38=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y

Regards,
Yann E. MORIN.

> 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>
> ---
>  package/binutils/binutils.mk | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/package/binutils/binutils.mk b/package/binutils/binutils.mk
> index 13cd02b491..b24e4334c2 100644
> --- a/package/binutils/binutils.mk
> +++ b/package/binutils/binutils.mk
> @@ -130,5 +130,17 @@ ifeq ($(BR2_BINUTILS_ENABLE_LTO),y)
>  HOST_BINUTILS_CONF_OPTS += --enable-plugins --enable-lto
>  endif
>  
> +# Hardlinks between binaries in different directories cause a problem
> +# with rpath fixup, so we de-hardlink those binaries, and replace them
> +# with symbolic links.
> +BINUTILS_TOOLS = ar as ld ld.bfd nm objcopy objdump ranlib readelf strip
> +define HOST_BINUTILS_FIXUP_HARDLINKS
> +	$(foreach tool,$(BINUTILS_TOOLS),\
> +		rm -f $(HOST_DIR)/$(GNU_TARGET_NAME)/bin/$(tool) ; \
> +		ln -s ../../bin/$(GNU_TARGET_NAME)-$(tool) $(HOST_DIR)/$(GNU_TARGET_NAME)/bin/$(tool)
> +	)
> +endef
> +HOST_BINUTILS_POST_INSTALL_HOOKS += HOST_BINUTILS_FIXUP_HARDLINKS
> +
>  $(eval $(autotools-package))
>  $(eval $(host-autotools-package))
> -- 
> 2.14.3
> 
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Thomas Petazzoni]

Hello,

On Mon, 23 Apr 2018 11:22:28 +0200, Yann E. MORIN wrote:

> So I wanted to test this, and it does what's on the can.
> 
> However, I wanted to reproduce the build failures, and here, with
> current master, so I built a toolchain with buildroot [0], but none
> of binutils programs is linked with libfl:
> 
>     $ for i in host/arc-buildroot-linux-uclibc/bin/*; do
>         readelf -d "${i}" |grep NEEDED
>     done |sort -u
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
> 
> I checked, and I don't have libfl on my system, neither static not
> shared, so it cant even have picked the static one from my system.
> 
> And indeed, libnl can build:
> 
>     checking the archiver (/home/ymorin/dev/buildroot/O/host/bin/arc-buildroot-linux-uclibc-ar)interface... ar
> 
> So, I don't see the point...
> 
> [0] with this defconfig:
> BR2_arcle=y
> BR2_archs38=y
> BR2_TOOLCHAIN_BUILDROOT_CXX=y

Here:

$ cat defconfig 
BR2_arcle=y
$ make host-binutils
$ readelf -d output/host/arc-buildroot-linux-uclibc/bin/ar 

Dynamic section at offset 0xb8de0 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libfl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000f (RPATH)              Library rpath: [/home/thomas/projets/buildroot/output/host/lib]

And indeed in the build process, I have:

/bin/sh ./libtool --tag=CC   --mode=link /usr/bin/gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I./../zlib -O2 -I/home/thomas/projets/buildroot/output/host/include  -L/home/thomas/projets/buildroot/output/host/lib -Wl,-rpath,/home/thomas/projets/buildroot/output/host/lib -o ar arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a -lfl  -ldl

To be honest, this is a bit weird, because for the other binutils,
which we build from a tarball, host-flex is not needed, and we don't
link against libfl.

See binutils/Makefile.am:

ar_LDADD = $(BFDLIB) $(LIBIBERTY) $(LEXLIB) $(LIBINTL)

and binutils/configure does check for the availability of a lex library. 

That being said, regardless of libfl specifically, I believe this
problem of hard links between binaries in different directories really
affects binutils anyway, and therefore, it makes sense to fix those to
use symlinks instead.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Yann E. MORIN]

Thomas, All,

On 2018-04-23 15:04 +0200, Thomas Petazzoni spake thusly:
> On Mon, 23 Apr 2018 11:22:28 +0200, Yann E. MORIN wrote:
> > However, I wanted to reproduce the build failures, and here, with
> > current master, so I built a toolchain with buildroot [0], but none
> > of binutils programs is linked with libfl:
[--SNIP--]
> And indeed in the build process, I have:
> /bin/sh ./libtool --tag=CC   --mode=link /usr/bin/gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I./../zlib -O2 -I/home/thomas/projets/buildroot/output/host/include  -L/home/thomas/projets/buildroot/output/host/lib -Wl,-rpath,/home/thomas/projets/buildroot/output/host/lib -o ar arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a -lfl  -ldl

And I too have a similar linking command, with your defconfig:

/bin/sh ./libtool --tag=CC   --mode=link /usr/bin/gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I./../zlib -O2 -I/home/ymorin/dev/buildroot/O2/host/include  -static-libstdc++ -static-libgcc -L/home/ymorin/dev/buildroot/O2/host/lib -Wl,-rpath,/home/ymorin/dev/buildroot/O2/host/lib -o ar arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o ../bfd/libbfd.la ../libiberty/libiberty.a -lfl  -ldl

which is turned into an actual link command:

libtool: link: /usr/bin/gcc -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Wstack-usage=262144 -I./../zlib -O2 -I/home/ymorin/dev/buildroot/O2/host/include -static-libstdc++ -static-libgcc -Wl,-rpath -Wl,/home/ymorin/dev/buildroot/O2/host/lib -o ar arparse.o arlex.o ar.o not-ranlib.o arsup.o rename.o binemul.o emul_vanilla.o bucomm.o version.o filemode.o -L/home/ymorin/dev/buildroot/O2/host/lib ../bfd/.libs/libbfd.a -L/home/ymorin/dev/buildroot/O2/build/host-binutils-arc-2018.03-rc1/zlib -lz ../libiberty/libiberty.a /home/ymorin/dev/buildroot/O2/host/lib/libfl.so -lm -ldl -Wl,-rpath -Wl,/home/ymorin/dev/buildroot/O2/host/lib -Wl,-rpath -Wl,/home/ymorin/dev/buildroot/O2/host/lib

So we can see that, yes, libfl.so *is* pulled in. Yet:

readelf -d host/arc-buildroot-linux-uclibc/bin/ar
Dynamic section at offset 0xd6a30 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/ymorin/dev/buildroot/O2/host/lib]
[--SNIP--]

So, WTF?

I'll be trying on another machine with an older system...

Regards,
Yann E. MORIN.

> To be honest, this is a bit weird, because for the other binutils,
> which we build from a tarball, host-flex is not needed, and we don't
> link against libfl.
> 
> See binutils/Makefile.am:
> 
> ar_LDADD = $(BFDLIB) $(LIBIBERTY) $(LEXLIB) $(LIBINTL)
> 
> and binutils/configure does check for the availability of a lex library. 
> 
> That being said, regardless of libfl specifically, I believe this
> problem of hard links between binaries in different directories really
> affects binutils anyway, and therefore, it makes sense to fix those to
> use symlinks instead.
> 
> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > 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.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Thomas Petazzoni]

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

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Yann E. MORIN]

Thomas, All,

On 2018-05-06 22:26 +0200, Thomas Petazzoni spake thusly:
> 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.

Yes, but since you had the problem, and the fix "makes sense", it's OK

Today, only binutils is affected, and I don't expect that a lot of
packages will have the same issue, so this binutils-specific fix is
also enough.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:

 > 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 to 2018.02.x, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] binutils: replace hard-links with soft-links to fix rpath

[Yann E. MORIN]

Peter, All,

On 2018-05-24 23:05 +0200, Peter Korsgaard spake thusly:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@bootlin.com> writes:
> 
>  > 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 to 2018.02.x, thanks.

As discussed on IRC, and so you don't forget, this will require further
backporting of fixes for bug #11031 when they are applied to master:
    https://patchwork.ozlabs.org/patch/921680/
    https://patchwork.ozlabs.org/patch/921681/

;-p

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'