Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 732482

Summary: sys-libs/musl: does not support sysroot installation
Product: Gentoo Linux Reporter: David Michael <fedora.dm0>
Component: Current packagesAssignee: Anthony Basile <blueness>
Status: RESOLVED FIXED    
Severity: normal CC: aladjev.andrew, balint, bertrand, gentoo, lu_zero, musl, opal, sam, toolchain
Priority: Normal Keywords: PATCH
Version: unspecified   
Hardware: All   
OS: Linux   
See Also: https://bugs.gentoo.org/show_bug.cgi?id=830214
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: fix
Patch for Makefile

Description David Michael 2020-07-13 15:40:39 UTC
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
Comment 1 Jory A. Pratt gentoo-dev 2020-07-19 23:38:27 UTC
Your using an invalid profile for one, all musl profiles use /usr/lib/ they are not multilib profiles.
Comment 2 David Michael 2020-07-20 00:16:03 UTC
Nope.  Please leave the issue open for someone who is familiar with sysroots.
Comment 3 Andrew Aladjev 2020-07-29 18:04:08 UTC
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.
Comment 4 Andrew Aladjev 2020-07-29 18:04:49 UTC
Created attachment 651460 [details, diff]
fix
Comment 5 David Michael 2020-07-29 19:18:04 UTC
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.
Comment 6 David Michael 2020-09-08 00:12:50 UTC
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.
Comment 7 Michael 'veremitz' Everitt 2020-09-11 00:40:51 UTC
Created attachment 659446 [details, diff]
Patch for Makefile

Suggested patch-file from upstream musl (credit to Rich Felkner, @dalias on IRC).

Please test.
Comment 8 David Michael 2020-09-11 01:21:12 UTC
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.
Comment 9 Rich Felker 2020-09-11 01:38:32 UTC
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 /.
Comment 10 David Michael 2020-09-11 01:51:24 UTC
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
Comment 11 Larry the Git Cow gentoo-dev 2021-11-10 03:32:39 UTC
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(-)
Comment 12 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-10 03:36:22 UTC
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).
Comment 13 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-11-10 03:37:36 UTC
(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.
Comment 14 Larry the Git Cow gentoo-dev 2021-11-16 02:58:59 UTC
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(-)
Comment 15 Larry the Git Cow gentoo-dev 2021-11-18 00:02:07 UTC
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(-)