This line kills the build if it can't find the ld.so symlink's target when not building a crossdev version of the package: https://github.com/gentoo/gentoo/blob/master/sys-libs/musl/musl-1.1.24.ebuild#L106 This prevents installing/updating musl in a sysroot because it uses an absolute symlink to /usr/lib/libc.so, which does not exist when the build system is amd64 using lib64. Reproducible: Always Steps to Reproduce: 1. emerge -v sys-libs/musl # with a sysroot profile Actual Results: * ERROR: sys-libs/musl-1.1.24::gentoo failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 125: Called src_install * environment, line 2295: Called die * The specific snippet of code: * [[ -e "${D}"/lib/ld-musl-${arch}.so.1 ]] || die; Expected Results: It should build and install. # ll /var/tmp/portage/sys-libs/musl-1.1.24/image/lib/ld-musl-x86_64.so.1 /usr/lib*/libc.so -rwxr-xr-x. 1 root root 253 Jul 6 09:17 /usr/lib64/libc.so lrwxrwxrwx. 1 root root 16 Jul 13 11:38 /var/tmp/portage/sys-libs/musl-1.1.24/image/lib/ld-musl-x86_64.so.1 -> /usr/lib/libc.so
Your using an invalid profile for one, all musl profiles use /usr/lib/ they are not multilib profiles.
Nope. Please leave the issue open for someone who is familiar with sysroots.
Hello. I've mentioned this issue several times both on gentoo bugtracker and musl mailing lists. Everybody knows that this issue exists, but forget to fix it. I am just using simple patch.
Created attachment 651460 [details, diff] fix
Thanks for that patch; using a relative symlink is the proper fix. I've just been deleting the bad test line from the ebuild to make it work.
One note about the patch, when using split-usr (i.e. /lib and /usr/lib are separate directories), the symlink works: /usr/x86_64-gentoo-linux-musl/lib/ld-musl-x86_64.so.1 -> ../usr/lib/libc.so When /lib is a symlink to /usr/lib, there is a broken link: /usr/x86_64-gentoo-linux-musl/usr/lib/ld-musl-x86_64.so.1 -> ../usr/lib/libc.so This link works as /lib/ld-musl-x86_64.so.1 when the binpkg is installed in a real root, but testing the sysroot for broken links will find it.
Created attachment 659446 [details, diff] Patch for Makefile Suggested patch-file from upstream musl (credit to Rich Felkner, @dalias on IRC). Please test.
It still makes a broken link when /lib is symlinked to /usr/lib: usr/lib/ld-musl-x86_64.so.1 -> ../usr/lib/libc.so Maybe I can just put EXTRA_EMAKE='syslibdir=$(libdir)' in the environment when split-usr is disabled.
I don't entirely understand what you're trying to do, but --prefix etc. are usually not the right way to install in a sysroot. --syslibdir should be left alone (never changed from /lib) and DESTDIR= should be used at make install time to install to the sysroot so that the layout there will be appropriate for the target using it as /.
I am just trying to use a UsrMerge layout where /lib is a symlink to /usr/lib. Testing the sysroot for broken links with this finds the link: ls -l $(find /usr/x86_64-gentoo-linux-musl -xtype l) lrwxrwxrwx. 1 root root 18 Sep 10 21:20 /usr/x86_64-gentoo-linux-musl/usr/lib/ld-musl-x86_64.so.1 -> ../usr/lib/libc.so
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a4957cb794dce725b4801ee16a36f38526bdce2d commit a4957cb794dce725b4801ee16a36f38526bdce2d Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-10 03:31:26 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-10 03:32:25 +0000 sys-libs/musl: create relative symlink to libc.so if existing one fails The build system seems to create an absolute symlink to libc.so on the host which may not exist. If it doesn't (to avoid being disruptive, we could do this unconditionally), create a new one relative within ${D} to facilitate SYSROOT installs. I've hit this a few times when using crossdev but finally dug into it a bit more. Bug: https://bugs.gentoo.org/732482 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/musl/musl-1.2.2-r4.ebuild | 167 +++++++++++++++++++++++++++++++++++++ sys-libs/musl/musl-9999.ebuild | 20 ++++- 2 files changed, 185 insertions(+), 2 deletions(-)
Workaround applied in Gentoo, anyway. To give a clearer example, this problem manifests when using crossdev on a glibc pure 64-bit (e.g. arm64 here) host to build a musl system (because /usr/lib/libc.so won't eixst, so the symlink is dead).
(In reply to Sam James from comment #12) > Workaround applied in Gentoo, anyway. > > To give a clearer example, this problem manifests when using crossdev on a > glibc pure 64-bit (e.g. arm64 here) host to build a musl system (because > /usr/lib/libc.so won't eixst, so the symlink is dead). Also, note that Alpine (while also shuffling around the files between /lib and /usr/lib) also (re-)create the symlinks relative to the image directory: https://git.alpinelinux.org/aports/tree/main/musl/APKBUILD#n103, it seems.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9f298f1a006956c0bf05b549146a90e141df5489 commit 9f298f1a006956c0bf05b549146a90e141df5489 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-16 02:58:10 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-16 02:58:15 +0000 sys-libs/musl: stabilize 1.2.2-r4 Trivial ebuild-only changes but I wanted to let it soak in ~arch for a bit. Bug: https://bugs.gentoo.org/732482 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/musl/musl-1.2.2-r4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=49f4daae534d359eb473556c4c6a6745bb37974e commit 49f4daae534d359eb473556c4c6a6745bb37974e Author: Sam James <sam@gentoo.org> AuthorDate: 2021-11-18 00:01:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-11-18 00:01:58 +0000 sys-libs/musl: fix symlink path again Bug: https://bugs.gentoo.org/732482 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/musl/musl-1.2.2-r4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
