| Message ID | 20221026125836.3910730-1-thomas.petazzoni@bootlin.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | package/musl: fixup the dynamic loader symlink | expand |
Thomas, All, On 2022-10-26 14:58 +0200, Thomas Petazzoni via buildroot spake thusly: > 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. [--SNIP--] > 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 What about external toolchains? Regards, Yann E. MORIN.
Hello Yann, On Wed, 26 Oct 2022 15:31:22 +0200 <yann.morin@orange.com> wrote: > What about external toolchains? That's a very good question, which I had not looked into, so I did some research. External toolchains are not affected because when we copy the sysroot from the toolchain into STAGING_DIR, we do this: for link in $$(find $(STAGING_DIR) -type l); do \ target=$$(readlink $${link}) ; \ if [ "$${target}" == "$${target$(SHARP_SIGN)/}" ] ; then \ continue ; \ fi ; \ relpath="$(call relpath_prefix,$${target$(SHARP_SIGN)/})" ; \ echo "Fixing symlink $${link} from $${target} to $${relpath}$${target$(SHARP_SIGN)/}" ; \ ln -sf $${relpath}$${target$(SHARP_SIGN)/} $${link} ; \ done ; \ (from toolchain/helpers.mk:copy_toolchain_sysroot) This causes this to happen: >>> toolchain-external-bootlin 2021.11-1 Copying external toolchain sysroot to staging... Fixing symlink /home/thomas/projets/buildroot/output/host/x86_64-buildroot-linux-musl/sysroot/lib/ld-musl-x86_64.so.1 from /lib/libc.so to ../lib/libc.so So in the external toolchain, even if the symlink is broken, it gets fixed when we import the toolchain into STAGING_DIR. (Note: the external toolchain used here is a Bootlin toolchain, produced by Buildroot, but without the musl.mk fix, so it does have the bogus ld-musl-x86-64.so.1 -> /lib/libc.so link, but that gets fixed when we import the toolchain, as described above) Does that this seem like a good enough answer for the external toolchain case? If so, I can submit a v2 with an amended commit log. Thanks! Thomas
Thomas, All, On 2022-10-26 20:53 +0200, Thomas Petazzoni spake thusly: > On Wed, 26 Oct 2022 15:31:22 +0200 > <yann.morin@orange.com> wrote: > > What about external toolchains? > External toolchains are not affected because when we copy the sysroot > from the toolchain into STAGING_DIR, we do this: [--SNIP--] > (from toolchain/helpers.mk:copy_toolchain_sysroot) Ah, so this is already handled explicitly as a generic fixup.² > Does that this seem like a good enough answer for the external > toolchain case? If so, I can submit a v2 with an amended commit log. Yes, this is perfect, thanks! Regards, Yann E. MORIN.
Thomas, All, On 2022-10-26 14:58 +0200, Thomas Petazzoni via buildroot spake thusly: > 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 > > Cc: hello.skyclo@gmail.com > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Applied to master, after adding a summary of the explanations you provided Yann about the external toolchain case. Thanks. Regards, Yann E. MORIN. > --- > 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)) > -- > 2.37.3 > > _______________________________________________ > buildroot mailing list > buildroot@buildroot.org > https://lists.buildroot.org/mailman/listinfo/buildroot
>>>>> "Thomas" == Thomas Petazzoni via buildroot <buildroot@buildroot.org> writes: > 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 > Cc: hello.skyclo@gmail.com > Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Committed to 2022.08.x and 2022.02.x, thanks.
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))
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 Cc: hello.skyclo@gmail.com Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> --- package/musl/musl.mk | 2 ++ 1 file changed, 2 insertions(+)