From 47e8cc8e8ef7c64799495888fb16e92578f7dbf6 Mon Sep 17 00:00:00 2001 From: Thomas Petazzoni Date: Wed, 26 Oct 2022 14:58:35 +0200 Subject: [PATCH] package/musl: fixup the dynamic loader symlink 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-.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 [yann.morin.1998@free.fr: - add summary of Thomas' explanations for external toolchains ] Signed-off-by: Yann E. MORIN (cherry picked from commit 7935e427bce601f16ee194978583e533213f78c6) Signed-off-by: Peter Korsgaard --- 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))