binutils: replace hard-links with soft-links to fix rpath

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 <[email protected]>

---
 package/binutils/binutils.mk | 12 ++++++++++++
 1 file changed, 12 insertions(+)

package/binutils/binutils.mk +12 -0

index 13cd02b491..b24e4334c2 100644
@@ -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))

Signature · 6 lines

2.14.3

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

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

Quoted 3 lines

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:

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

Signature · 3 lines

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

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> 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 <[email protected]>

Quoted 23 lines

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.

Quoted 5 lines

Fixes:

http://autobuild.buildroot.net/results/b2562b05d397d4e1ffe0f8d2f4ce4c84ab6feae1/

Signed-off-by Thomas Petazzoni <[email protected]>

Committed, thanks.

Quoted 30 lines

Quoted 29 lines

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 <[email protected]>

Quoted 1 line

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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> 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 <[email protected]>

Quoted 25 lines

Quoted 1 line

Quoted 1 line

Quoted 1 line

Quoted 1 line

"Thomas" == Thomas Petazzoni <[email protected]> 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.

Quoted 5 lines

Fixes:

http://autobuild.buildroot.net/results/b2562b05d397d4e1ffe0f8d2f4ce4c84ab6feae1/

Signed-off-by Thomas Petazzoni <[email protected]>

Committed to 2018.02.x, thanks.