The musl ebuild now tries to create an ldd symlink. However this breaks the build for crossdev targets. (The error message is something along the line "dosym: requires two arguments".) Another problem is that for crossdev targets the dynamic linker should be installed into /lib/ld-musl-* instead of /usr/${CTARGET}/lib/ld-musl-*. (Because the dynamic loader path is hardcoded.) Thirdly, the make.profile symlink in /usr/${CTARGET}/etc/make.conf is wrong. This seems to be an issue in crossdev, though. Reproducible: Always
Created attachment 399484 [details, diff] Proposed patch against musl ebuild The patch should fix issues 1 & 2. gcc does not seem to need the sys-include link anymore. I've tested building musl natively and recreating a crossdev toolchain.
*** Bug 544126 has been marked as a duplicate of this bug. ***
(In reply to Felix Janda from comment #1) > Created attachment 399484 [details, diff] [details, diff] > Proposed patch against musl ebuild > > The patch should fix issues 1 & 2. > > gcc does not seem to need the sys-include link anymore. > > I've tested building musl natively and recreating a crossdev toolchain. Thanks, I don't have to cross compile, so I didn't notice this, but both points are legit. I'll add that without a rev bump later.
Created attachment 399758 [details, diff] Proposed patch against musl ebuild The previous patch would have moved the dynamic linker of a crosscompiler to /lib instead of /usr/$CTARGET/lib. Fix this by passing --syslibdir to musl's configure script.
(In reply to Felix Janda from comment #4) > Created attachment 399758 [details, diff] [details, diff] > Proposed patch against musl ebuild > > The previous patch would have moved the dynamic linker of a > crosscompiler to /lib instead of /usr/$CTARGET/lib. Fix this by passing > --syslibdir to musl's configure script. I (In reply to Felix Janda from comment #4) > Created attachment 399758 [details, diff] [details, diff] > Proposed patch against musl ebuild > > The previous patch would have moved the dynamic linker of a > crosscompiler to /lib instead of /usr/$CTARGET/lib. Fix this by passing > --syslibdir to musl's configure script. I changed your first hunk to the following: + local sysroot=/ + is_crosscompile && sysroot=/usr/${CTARGET} ./configure \ --target="${CTARGET}" \ - --prefix="/usr" \ + --prefix=${sysroot}/usr \ + --syslibdir=${sysroot}/lib \ --disable-gcc-wrapper Note: I initialized sysroot to / and I removed the quotes around ${sysroot} to avoid the double //, which probably doesn't matter anyhow when being passed to --prefix= or --syslibdir=. This is what you do in the second hunk. There you definitely want to avoid quotes around sysroot else you get ld-musl-x86_64.so.1 -> //usr/lib/libc.so I feel better about avoiding an non-explicitly initialized value for sysroot. It works for native, please test for cross. Its in as 1.1.7-r1 all ~arch. Reopen if there is still a problem.
Actually, followup. You need sysroot unset in order to avod the double //, so I checked and `local sysroot` does infact leave sysroot unset which is fine here.
Created attachment 399888 [details, diff] Patch against -r1 musl-1.1.7-r1 does not yet work correctly for crossdev. (I didn't realise that changing --syslibdir would require more changes in the ebuild.) Have now updated native and several crossdev version of musl successfully.
Okay I'll give it a test natively and then commit.
(In reply to Anthony Basile from comment #8) > Okay I'll give it a test natively and then commit. Its in the tree now with 1.1.7-r2. It works fine for native an looks okay for cross, but please test cross again and reopen if its still broken.
I'm still requesting the script not to fail when there are several /lib/ld-musl-*.so.1 . Since it is now in the musl ebuild we can find out the right name and modify ldconfig accordingly. Is this undesirable?
(In reply to Felix Janda from comment #10) > I'm still requesting the script not to fail when there are several > /lib/ld-musl-*.so.1 . Since it is now in the musl ebuild we can > find out the right name and modify ldconfig accordingly. Is this > undesirable? I assume you're referring to the ldconfig script? So you would like this line changed: LDSO_PATH=$(ls /lib/ld-musl-*.so.1) to something without the globbing and we should be able to do that in the ebuild because we know the arch? The reason I went this way was because it makes the same script cross arch and you can just drop it in (without substitution) and it just works. However, if this is breaking with crossdev, then I'm willing to write an ldconfig.in file and have some substitution in the ebuild which adds the correct arch where the glob is above. Also it might be good to know under what conditions the glob gets confused? ie when would you have several /lib/ld-musl-*.so.1? I'll reopen for continued discussion.
Sorry, I commented on the wrong bug... Yes, I'm refering to the ldconfig script and that line. It gets confused when there are several /lib/ld-musl-*.so.1 . With crossdev ld-musl-*.so.1 will be put into /usr/${CTARGET}/... So this is really this wrong bug to comment on... However when cross-compiling musl externally (say for an arch not supported by crossdev) by default ld-musl-*.so.1 will be put into /lib while the rest will be put into the prefix /usr/local/musl. This makes it not very difficult to have several ld-musl-*.so.1 in /lib. The intention of this design is that the resulting binaries can be directly run (with qemu user emulation if the arch is different) on the system (without a chroot). Actually since we already (should?!) have an /etc/env.d/00musl we could put some helpful environment variable inside and use that to have an arch independent ldconfig script which does not fail when there are several /lib/ld-musl-*.so.1.
(In reply to Felix Janda from comment #12) > Sorry, I commented on the wrong bug... > > Yes, I'm refering to the ldconfig script and that line. It gets > confused when there are several /lib/ld-musl-*.so.1 . > > With crossdev ld-musl-*.so.1 will be put into /usr/${CTARGET}/... > So this is really this wrong bug to comment on... > > However when cross-compiling musl externally (say for an arch not > supported by crossdev) by default ld-musl-*.so.1 will be put > into /lib while the rest will be put into the prefix /usr/local/musl. > This makes it not very difficult to have several ld-musl-*.so.1 in > /lib. The intention of this design is that the resulting binaries > can be directly run (with qemu user emulation if the arch is > different) on the system (without a chroot). Understood. > > Actually since we already (should?!) have an /etc/env.d/00musl we > could put some helpful environment variable inside and use that > to have an arch independent ldconfig script which does not fail > when there are several /lib/ld-musl-*.so.1. Thanks. I forgot to add 00musl in 1.1.8-r1. Its in 1.1.8-r2 and 9999. I don't like the idea of *just* an environment variable since that can be fragile. We need to also have a hardcoded fallback value especially on systems where musl is native. Although I'd like ldconfig to be cross platform, i'm not against sed-ing it in the build for the particular arch in question. We can do that *and* have an overriding env variable. If set wrong, it would just screw up that shell (and children) and not the entire system. Would that statisfy the cross compiling needs?
Thanks for adding 00musl. For not getting confused about multiple /lib/ld-musl-*.so.1 certainly any of the solutions you are proposing works. Another way to make use of 00musl, would be to use LDPATH to insert a (commented) line at the beginning of /etc/ld.so.conf with the name of the dynamic linker name. We are already reading /etc/ld.so.conf anyway and if there is some comment not to remove that line, the user trying to remove that line has been warned...
(In reply to Felix Janda from comment #14) > Thanks for adding 00musl. > > For not getting confused about multiple /lib/ld-musl-*.so.1 certainly > any of the solutions you are proposing works. > > Another way to make use of 00musl, would be to use LDPATH to insert > a (commented) line at the beginning of /etc/ld.so.conf with the name > of the dynamic linker name. We are already reading /etc/ld.so.conf > anyway and if there is some comment not to remove that line, the > user trying to remove that line has been warned... Please test musl-1.1.9.ebuild in a cross compiling env. I've changed how the ldconfig script is built and it no longer does LDSO_PATH=$(ls /lib/ld-musl-*.so.1) but rather check the target arch and adds the correct value for LDSO_PATH.
Thanks! The new ldconfig works fine in my setup. For crossdev no ldconfig is installed.
