[Buildroot] [git commit] package/musl: fixup the dynamic loader symlink

[Buildroot] [git commit] package/musl: fixup the dynamic loader symlink

[Yann E. MORIN]

commit: https://git.buildroot.net/buildroot/commit/?id=7935e427bce601f16ee194978583e533213f78c6
branch: https://git.buildroot.net/buildroot/commit/?id=refs/heads/master

The musl Makefile installs the dynamic loader as a symlink to libc.so
with the following rule:

$(DESTDIR)$(LDSO_PATHNAME): $(DESTDIR)$(libdir)/libc.so
        $(INSTALL) -D -l $(libdir)/libc.so $@ || true

While it works, the drawback is that ld-musl-<arch>.so ends up being a
symlink to /lib/libc.so. While it works on the target, it means we
have a broken symlink in $(STAGING_DIR) and $(TARGET_DIR) as
/lib/libc.so doesn't make sense on the build machine. This generally
doesn't cause any problem *except* when we tell Qemu to use
$(STAGING_DIR) as the library directory when running target programs
through the Qemu user emulation mode. This is for example node inside
the NodeJS build. Due to this broken symlink, Qemu can't find libc.so
that is pointed to be the dynamic loader symlink causing this build
error:

qemu-arm: Could not open '/lib/ld-musl-armhf.so.1': No such file or directory

Since this is not really a bug in the musl build system, we address
this issue by overriding the symlink to be a relative path. The
dynamic loader is always installed in /lib, and libc.so is also always
installed in /lib because we pass libdir=/lib when configuring
musl. So we can simply have a ld-musl* -> libc.so symbolic link. We
use ld-musl* as a wildcard so that we don't need to have extra logic
to determine the exact name of the dynamic loader symlink, and simply
override the one that exists.

Fixes:

  http://autobuild.buildroot.net/results/9ff23f2e3c97e9af410617de3e7376f9d45a7d63/
  https://bugs.busybox.net/show_bug.cgi?id=15061

Note that, for external toolchain, we already have a generic fixup that
makes symlinks relative [0]. So in the external toolchain, even if the
symlink is broken, it gets fixed when we import the toolchain into
STAGING_DIR.

[0] https://lore.kernel.org/buildroot/20221026205312.3f729eb8@windsurf/

Cc: hello.skyclo@gmail.com
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
  - add summary of Thomas' explanations for external toolchains
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
---
 package/musl/musl.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/package/musl/musl.mk b/package/musl/musl.mk
index 44c79da6f7..30c3c2fbc0 100644
--- a/package/musl/musl.mk
+++ b/package/musl/musl.mk
@@ -60,12 +60,14 @@ endef
 define MUSL_INSTALL_STAGING_CMDS
 	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
 		DESTDIR=$(STAGING_DIR) install-libs install-tools install-headers
+	ln -sf libc.so $(STAGING_DIR)/lib/ld-musl*
 endef
 
 define MUSL_INSTALL_TARGET_CMDS
 	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D) \
 		DESTDIR=$(TARGET_DIR) install-libs
 	$(RM) $(addprefix $(TARGET_DIR)/lib/,crt1.o crtn.o crti.o rcrt1.o Scrt1.o)
+	ln -sf libc.so $(TARGET_DIR)/lib/ld-musl*
 endef
 
 $(eval $(generic-package))
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot