Aside from pure compilation issues from the differences between musl and glibc (and the inability to build dev-util/ninja #663216), a meson conf error occurs at ${S}/src/boot/efi/meson.build:54, in that musl's gcc -print-multi-os-directory returns ../lib64, which does not exist on a musl 17.0 profile. Symlinking lib64 to lib makes this work and allows me to get at the actual build errors.
systemd does not support anything but glibc.
(In reply to Mike Gilbert from comment #1) > systemd does not support anything but glibc. Aware, but this has revealed a musl/gcc issue unrelated to the libc, strictly speaking. We can fix that issue, at least, in that while gcc for musl is built with --disable-multilib and the profiles have LIBDIR_amd64="lib", gcc -print-multi-os-directory returns ../lib64, which obviously does not exist.
Let's mention that in the summary then.
(In reply to hanetzer from comment #2) > (In reply to Mike Gilbert from comment #1) > > systemd does not support anything but glibc. > > Aware, but this has revealed a musl/gcc issue unrelated to the libc, > strictly speaking. We can fix that issue, at least, in that while > gcc for musl is built with --disable-multilib and the profiles have > LIBDIR_amd64="lib", gcc -print-multi-os-directory returns ../lib64, > which obviously does not exist. You mentioned in IRC some patches from alpine. Do you want to get a PR on github so I can review and commit.
../lib64 mangling happens at https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n763 Which should be cleaned for you by 'is_multilib || return 0'. That is defined as: is_multilib() { tc_version_is_at_least 3 || return 1 use_if_iuse multilib } I don't see your 'emerge --info' and can't check profile name. Make sure your prifile includes 'arch/amd64/no-multilib'.
Created attachment 562520 [details] emerge --info
(In reply to Sergei Trofimovich from comment #5) > ../lib64 mangling happens at > > https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n763 > > Which should be cleaned for you by 'is_multilib || return 0'. > That is defined as: > is_multilib() { > tc_version_is_at_least 3 || return 1 > use_if_iuse multilib > } > > I don't see your 'emerge --info' and can't check profile name. > > Make sure your prifile includes 'arch/amd64/no-multilib'. profile default/linux/amd64/17.0/musl's parent file contains ../../../../../arch/amd64/no-multilib
(In reply to hanetzer from comment #7) > profile default/linux/amd64/17.0/musl's parent file contains > ../../../../../arch/amd64/no-multilib Thank you! Now I see the same behaviour locally. I wonder if it's caused by passing contradicting options into gcc: * --disable-multilib * --with-multilib-list=m64
Had a more detailed look at how gcc generates multilib specs. Non-multilib systems usually look like this: $ armv7a-unknown-linux-gnueabihf-gcc -dumpspecs | grep -A1 multilib *multilib: . ; -- *multilib_defaults: -- Multilib x86_64 looks like this: $ x86_64-pc-linux-gnu-gcc -dumpspecs | grep -A1 multilib *multilib: . !m32 !m64;32:../lib32 m32 !m64;64:../lib64 !m32 m64; -- *multilib_defaults: m64 -- Musl inherits the same setup: $ x86_64-gentoo-linux-musl-gcc -dumpspecs | grep -A1 multilib *multilib: . !m64 !m32;.:../lib64 m64 !m32;.:../lib !m64 m32; -- *multilib_defaults: m64 -- This happens because musl inherits x86_64 structure: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/t-linux64#L33 MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-linux-gnu) MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:i386-linux-gnu) MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-linux-gnux32) https://github.com/gcc-mirror/gcc/blob/master/gcc/config/t-musl#L2 MULTILIB_OSDIRNAMES := $(subst -linux-gnu,-linux-musl,$(MULTILIB_OSDIRNAMES)) It's used at genmultilib site: https://github.com/gcc-mirror/gcc/blob/master/gcc/Makefile.in#L2052 multilib.h: s-mlib; @true s-mlib: $(srcdir)/genmultilib Makefile if test @enable_multilib@ = yes \ || test -n "$(MULTILIB_OSDIRNAMES)"; then \ $(SHELL) $(srcdir)/genmultilib \
If musl is really incapable of any multilib support we can work it around by dropping multilib layout completely: --- a/gcc/config/t-musl +++ b/gcc/config/t-musl @@ -1,2 +1,3 @@ MULTIARCH_DIRNAME := $(subst -linux-gnu,-linux-musl,$(MULTIARCH_DIRNAME)) -MULTILIB_OSDIRNAMES := $(subst -linux-gnu,-linux- musl,$(MULTILIB_OSDIRNAMES)) +# No real multilib support. Default to 'lib': https://bugs.gentoo.org/675954 +MULTILIB_OSDIRNAMES :=
Created attachment 562928 [details, diff] gcc-musl.patch
Note: gentoo explicitly passes /lib as a system library path when builds musl: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/musl/musl-1.1.20-r1.ebuild#n68 src_configure() { ./configure \ --syslibdir=${sysroot}/lib \ I suggest musl@ team to consider two things: 1. switch to '--syslibdir=${sysroot}/$(get_libdir)' to untangle from hardcoded /lib setup 2a. consider switching to LIBDIR_amd64="lib64" as it matches gcc's expectation. 2b. or as an alternative to [2a.] upstream something like gcc-musl.patch after coordination with musl upstream.
(In reply to Sergei Trofimovich from comment #12) > Note: gentoo explicitly passes /lib as a system library path when builds > musl: > > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/musl/musl-1.1.20-r1. > ebuild#n68 > src_configure() { > ./configure \ > --syslibdir=${sysroot}/lib \ > > I suggest musl@ team to consider two things: > 1. switch to '--syslibdir=${sysroot}/$(get_libdir)' to untangle from > hardcoded /lib setup > 2a. consider switching to LIBDIR_amd64="lib64" as it matches gcc's > expectation. > 2b. or as an alternative to [2a.] upstream something like gcc-musl.patch > after coordination with musl upstream. Regarding LIBDIR_amd64="lib64" I was talkin with folks in freenode/#musl and they seem to be of the impression that's entirely wrong, at least for the ldso... I seem to recall some new abi doc saying 32-bit libs are supposed to go in /lib and /usr/lib and 64-bit libs to /lib64 and /usr/lib64, part of the rationale for the new 17.1 profiles. Do you happen to know it off hand?
(In reply to hanetzer from comment #13) > (In reply to Sergei Trofimovich from comment #12) > > Note: gentoo explicitly passes /lib as a system library path when builds > > musl: > > > > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/musl/musl-1.1.20-r1. > > ebuild#n68 > > src_configure() { > > ./configure \ > > --syslibdir=${sysroot}/lib \ > > > > I suggest musl@ team to consider two things: > > 1. switch to '--syslibdir=${sysroot}/$(get_libdir)' to untangle from > > hardcoded /lib setup > > 2a. consider switching to LIBDIR_amd64="lib64" as it matches gcc's > > expectation. > > 2b. or as an alternative to [2a.] upstream something like gcc-musl.patch > > after coordination with musl upstream. > > Regarding LIBDIR_amd64="lib64" I was talkin with folks in freenode/#musl and > they seem to be of the impression that's entirely wrong, at least for the > ldso. I fail to parse it. What is "that's entirely wrong" here? [1.], [2a.] or [2ab.]? '--syslibdir=${sysroot}/lib' or '--syslibdir=${sysroot}/$(get_libdir)' or LIBDIR_amd64="lib64"? Or something else? Please be specific. ld.so placement is separate to from general shared libraries location. We can always add a single-file symlink to /lib. We do it for glibc at: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.28-r5.ebuild#n1148 musl can do the same single-file symlink. gcc uses /lib/ for musl's ld.so: i386/linux64.h:#define MUSL_DYNAMIC_LINKER64 "/lib/ld-musl-x86_64.so.1" > I seem to recall some new abi doc saying 32-bit libs are supposed to > go in /lib and /usr/lib and 64-bit libs to /lib64 and /usr/lib64, part of the > rationale for the new 17.1 profiles. Do you happen to know it off hand? I don't think there are any docs beyond multilib-amd64-glibc gentoo wiki page.
(In reply to Sergei Trofimovich from comment #14) > (In reply to hanetzer from comment #13) > > (In reply to Sergei Trofimovich from comment #12) > > > Note: gentoo explicitly passes /lib as a system library path when builds > > > musl: > > > > > > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/musl/musl-1.1.20-r1. > > > ebuild#n68 > > > src_configure() { > > > ./configure \ > > > --syslibdir=${sysroot}/lib \ > > > > > > I suggest musl@ team to consider two things: > > > 1. switch to '--syslibdir=${sysroot}/$(get_libdir)' to untangle from > > > hardcoded /lib setup > > > 2a. consider switching to LIBDIR_amd64="lib64" as it matches gcc's > > > expectation. > > > 2b. or as an alternative to [2a.] upstream something like gcc-musl.patch > > > after coordination with musl upstream. > > > > Regarding LIBDIR_amd64="lib64" I was talkin with folks in freenode/#musl and > > they seem to be of the impression that's entirely wrong, at least for the > > ldso. > > I fail to parse it. What is "that's entirely wrong" here? [1.], [2a.] or > [2ab.]? '--syslibdir=${sysroot}/lib' or > '--syslibdir=${sysroot}/$(get_libdir)' or LIBDIR_amd64="lib64"? Or something > else? Please be specific. > > ld.so placement is separate to from general shared libraries location. We > can always add a single-file symlink to /lib. We do it for glibc at: > > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.28-r5. > ebuild#n1148 > musl can do the same single-file symlink. > > gcc uses /lib/ for musl's ld.so: > i386/linux64.h:#define MUSL_DYNAMIC_LINKER64 "/lib/ld-musl-x86_64.so.1" > > > I seem to recall some new abi doc saying 32-bit libs are supposed to > > go in /lib and /usr/lib and 64-bit libs to /lib64 and /usr/lib64, part of the > > rationale for the new 17.1 profiles. Do you happen to know it off hand? > > I don't think there are any docs beyond multilib-amd64-glibc gentoo wiki > page. Ah yeah, I misrememberd. its just ld-musl-$ARCH.so.1 that needs to go into /lib
Created attachment 572398 [details, diff] drop lib64 for musl users Well the original patch would work the proper solution IMO would be as smaeul has demonstrated in the new patch. He has been using the patch since 5.4.0 which also fixes binutil-lib to install to /lib and not /lib64 as current builds do.
(In reply to Jory A. Pratt from comment #16) > Created attachment 572398 [details, diff] [details, diff] > drop lib64 for musl users > > Well the original patch would work the proper solution IMO would be as > smaeul has demonstrated in the new patch. He has been using the patch since > 5.4.0 which also fixes binutil-lib to install to /lib and not /lib64 as > current builds do. This patch changes lib64 to lib in gcc-fixed/gcc/config/i386/t-linux64 That is used by all linux targets. Not just musl.
(In reply to Sergei Trofimovich from comment #17) > (In reply to Jory A. Pratt from comment #16) > > Created attachment 572398 [details, diff] [details, diff] [details, diff] > > drop lib64 for musl users > > > > Well the original patch would work the proper solution IMO would be as > > smaeul has demonstrated in the new patch. He has been using the patch since > > 5.4.0 which also fixes binutil-lib to install to /lib and not /lib64 as > > current builds do. > > This patch changes lib64 to lib in gcc-fixed/gcc/config/i386/t-linux64 > That is used by all linux targets. Not just musl. Correct. That patch can't be integrated into your patchset, but we can integrate it within a patchset only for musl the way we do for uclibc via the toolchain.eclass. I know the the better way to do this is to add the magic checks/flags to allow choice during build time, and then ideally send the patch upstream, but this is easier said than done with gcc. We had to deal with this with the hardened gcc patchset where we had to patch configure directly (yes configure, not configure.ac). I think its time to expand toolchain.eclass to include patches contingent on [[ ${CTARGET} == *-musl* ]].
If you think gcc needs to change why not upstream something that brings upstream gcc in line with what Gentoo expects? Then we would pull in something that just works. Keeping these workarounds downstream makes it hard to reason about actually used conventions (lib vs. lib64 vs. lib32).
(In reply to Sergei Trofimovich from comment #19) > If you think gcc needs to change why not upstream something that brings > upstream gcc in line with what Gentoo expects? Then we would pull in > something that just works. > > Keeping these workarounds downstream makes it hard to reason about actually > used conventions (lib vs. lib64 vs. lib32). These changes are not going to get upstreamed easily. It took years before the uclibc patches could finally be dropped. The uclibc and musl patchset would only apply to those systems.
(In reply to Anthony Basile from comment #20) > (In reply to Sergei Trofimovich from comment #19) > > If you think gcc needs to change why not upstream something that brings > > upstream gcc in line with what Gentoo expects? Then we would pull in > > something that just works. > > > > Keeping these workarounds downstream makes it hard to reason about actually > > used conventions (lib vs. lib64 vs. lib32). > > These changes are not going to get upstreamed easily. It took years before > the uclibc patches could finally be dropped. The uclibc and musl patchset > would only apply to those systems. It's not clear if you intend to upstream something or not eventually. Do you? If you do I suggest to get an agreement with gcc upstream on the end state. Preparing upstreamable patches will not be hard.
(In reply to Sergei Trofimovich from comment #21) > It's not clear if you intend to upstream something or not eventually. Do you? What makes you ask that? Of course I want an upstream solution, the problem is I need a stop gap. We have always done this with gcc --- consider the hardened gcc patches that Zorry worked on for years before they got upstream. We maintained those as a separate patchset against gcc until they could be upstreamed. > Preparing upstreamable patches will not be hard. I'm not so sure. There is precedence for what I'm asking. Currently, the toolchain.eclass has the following for uclibc which we've had and used for years. It was added by vapier. I don't see why we can't expand this practice to include musl. [[ -n ${UCLIBC_VER} ]] && \ GCC_SRC_URI+=" $(gentoo_urls gcc-${UCLIBC_GCC_VER}-uclibc-patches-${UCLIBC_VER}.tar.bz2)" Once again, I would point out that this would not affect glibc systems and without this, we're forcing musl to use gcc from the musl overlay rather than allowing it to be brought into the tree as we work to get everything upstreamed.
Sorry, I reread my message and didn't want it to be misleading. What I meant to say is that the toolchain.eclass has *lots* of lines like [[ -n ${UCLIBC_VER} ]] && \ GCC_SRC_URI+=" $(gentoo_urls gcc-${UCLIBC_GCC_VER}-uclibc-patches-${UCLIBC_VER}.tar.bz2)" and [[ -n ${UCLIBC_VER} ]] && \ unpack gcc-${UCLIBC_GCC_VER}-uclibc-patches-${UCLIBC_VER}.tar.bz2 and if [[ -n ${UCLIBC_VER} ]] ; then guess_patch_type_in_dir "${WORKDIR}"/uclibc EPATCH_MULTI_MSG="Applying uClibc patches ..." \ epatch "${WORKDIR}"/uclibc fi Not just the one line I quoted.
(In reply to Anthony Basile from comment #23) > Sorry, I reread my message and didn't want it to be misleading. What I meant > to say is that the toolchain.eclass has *lots* of lines like > > [[ -n ${UCLIBC_VER} ]] && \ > GCC_SRC_URI+=" $(gentoo_urls > gcc-${UCLIBC_GCC_VER}-uclibc-patches-${UCLIBC_VER}.tar.bz2)" > > and > > [[ -n ${UCLIBC_VER} ]] && \ > unpack gcc-${UCLIBC_GCC_VER}-uclibc-patches-${UCLIBC_VER}.tar.bz2 > > and > > > if [[ -n ${UCLIBC_VER} ]] ; then > guess_patch_type_in_dir "${WORKDIR}"/uclibc > EPATCH_MULTI_MSG="Applying uClibc patches ..." \ > epatch "${WORKDIR}"/uclibc > fi > > Not just the one line I quoted. None of them are conditional patches. The apply on glibc systems as well. For example gcc-5.5.0 reports for my glibc system: * Applying uClibc patches ... * 90_all_100-uclibc-conf.patch ... * 90_all_302-c99-snprintf.patch ... I'm not against unconditional patches.
(In reply to Anthony Basile from comment #22) > (In reply to Sergei Trofimovich from comment #21) > > It's not clear if you intend to upstream something or not eventually. Do you? > > What makes you ask that? Of course I want an upstream solution, the problem > is I need a stop gap. We have always done this with gcc --- consider the > hardened gcc patches that Zorry worked on for years before they got > upstream. We maintained those as a separate patchset against gcc until they > could be upstreamed. > > > Preparing upstreamable patches will not be hard. > > I'm not so sure. I expect 2 lines patch for this issue. The problem for me is I'm not sure gcc needs to change at all. #c12 has a few alternatives to follow in Gentoo. I see no explicit answer from musl@ on: - what is desired end state - whether gcc upstream agrees on end state (do we have bug/mail-thread against upstream?)
(In reply to Sergei Trofimovich from comment #12) > Note: gentoo explicitly passes /lib as a system library path when builds > musl: > > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/musl/musl-1.1.20-r1. > ebuild#n68 > src_configure() { > ./configure \ > --syslibdir=${sysroot}/lib \ > > I suggest musl@ team to consider two things: > 1. switch to '--syslibdir=${sysroot}/$(get_libdir)' to untangle from > hardcoded /lib setup > 2a. consider switching to LIBDIR_amd64="lib64" as it matches gcc's > expectation. > 2b. or as an alternative to [2a.] upstream something like gcc-musl.patch > after coordination with musl upstream. 2a would require serious work to migrate from the current gentoo implementation. amd64 musl gentoo is being used commercially and so an air tight migration plan would have to be in place to not break those systems. I'm not prepared to do this. Also, I'm not sure gcc's expectations matches any standards. Do you know of any such standards on the naming of /lib* directories? I'm not sure what you mean by 2b. > I'm not against unconditional patches. "unconditional" is relative. While those patches are unconditionally added by the eclass, they are not unconditionally incorporated into gcc. So, the 90_all_302-c99-snprintf.patch has lines like -#ifdef _GLIBCXX_USE_C99 +#if defined(_GLIBCXX_USE_C99) || defined(__UCLIBC__) Since uclibc defines this macro, the conditional check happens in the patch. However musl has stubbornly refused to define such a macro. See https://wiki.musl-libc.org/faq.html. You are right to point out that the conditional check is not in the eclass, which I mis-remembered. (FYI the final solution here, if I recall correctly, was the break _GLIBCXX_USE_C99 into several macros.) The end state is to have `gcc -print-multi-os-directory` behave as stated in the man page for non-multilib systems. Quoting: -print-multi-os-directory Print the path to OS libraries for the selected multilib, relative to some lib subdirectory. If OS libraries are present in the lib subdirectory and no multilibs are used, this is usually just ., if OS libraries are present in libsuffix sibling directories this prints e.g. ../lib64, ../lib or ../lib32, or if OS libraries are present in lib/subdir subdirectories it prints e.g. amd64, sparcv9 or ev6. I read this as saying that it should return either . or ../lib in our case. It ought to be possible to build gcc with that behavior on a musl system, either with a patch or without. Possibly we could just modify the eclass at setup_multilib_osdirnames() without any patch. A related goal is to get the gcc ebuild out of the musl overlay and have whatever musl support is needed in the main tree. (This is part of the larger goal of removing the hard dependency on the musl overlay for building @system and catalyst stages.)
(In reply to Anthony Basile from comment #26) > (In reply to Sergei Trofimovich from comment #12) > > Note: gentoo explicitly passes /lib as a system library path when builds > > musl: > > > > https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/musl/musl-1.1.20-r1. > > ebuild#n68 > > src_configure() { > > ./configure \ > > --syslibdir=${sysroot}/lib \ > > > > I suggest musl@ team to consider two things: > > 1. switch to '--syslibdir=${sysroot}/$(get_libdir)' to untangle from > > hardcoded /lib setup > > 2a. consider switching to LIBDIR_amd64="lib64" as it matches gcc's > > expectation. > > 2b. or as an alternative to [2a.] upstream something like gcc-musl.patch > > after coordination with musl upstream. > > 2a would require serious work to migrate from the current gentoo > implementation. amd64 musl gentoo is being used commercially and so an air > tight migration plan would have to be in place to not break those systems. > I'm not prepared to do this. But you are prepared to change upstream gcc to account for this use case? I'd like to see upstream gcc to be onboard with this plan. > Also, I'm not sure gcc's expectations matches any standards. Do you know of > any such standards on the naming of /lib* directories? AFAIU there are none. gcc implementation is the standard. > I'm not sure what you mean by 2b. [2a.] changes gentoo, [2b.] changes upstream gcc. > The end state is to have `gcc -print-multi-os-directory` behave as stated in > the man page for non-multilib systems. ... > I read this as saying that it should return either . or ../lib in our case. I read that musl@ does not plan to switch from /lib and wants /lib to be end state. Is that correct? > It ought to be possible to build gcc with that behavior on a musl system, > either with a patch or without. Possibly we could just modify the eclass at > setup_multilib_osdirnames() without any patch. Today musl has no multilib profiles. setup_multilib_osdirnames() tries hard to be a no-op for such cases. Note that we do mangle MULTILIB_OSDIRNAMES only for ${SYMLINK_LIB} == "yes" case. Gentoo's long term plan is to stop that and stick to upstream definition of library locations. It looks like musl goes in the opposite direction.
Also note that other tools assume matching layout. For example binutils does the same lib/lib64 assumption: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=ld/emultempl/elf32.em;h=3e8ee4693e67851e9f497a7393784a8c17bbf8bd;hb=HEAD#l606 606 case 'L': 607 if (strcmp (v, "IB") == 0 || strcmp (v, "IB}") == 0) 608 { 609 /* LIB - replace with "lib" in 32-bit environments 610 and "lib64" in 64-bit environments. */ 611 612 /* Note - we could replace this switch statement by 613 conditional fragments of shell script, but that is messy. 614 Any compiler worth its salt is going to optimize away 615 all but one of these case statements anyway. */ 616 switch ($ELFSIZE) 617 { 618 case 32: replacement = "lib"; break; 619 case 64: replacement = "lib64"; break; 620 default: 621 /* $ELFSIZE is not 32 or 64 ... */ 622 abort (); 623 } 624 } 625 break;
(In reply to Sergei Trofimovich from comment #27) > > But you are prepared to change upstream gcc to account for this use case? > I'd like to see upstream gcc to be onboard with this plan. > With respect, but this is disingenuous. A compile time switch could address this, so yes, I'd like to see something like that upstream, but its unlikely to happen easily. > AFAIU there are none. gcc implementation is the standard. This is a problem because there are other compilers. An implementation can't de facto be a standard. > > > I'm not sure what you mean by 2b. > > [2a.] changes gentoo, [2b.] changes upstream gcc. > > > The end state is to have `gcc -print-multi-os-directory` behave as stated in > > the man page for non-multilib systems. > ... > > I read this as saying that it should return either . or ../lib in our case. > > I read that musl@ does not plan to switch from /lib and wants /lib to be end > state. Is that correct? Why are you framing this as an issue of what musl@ wants rather than what it is reasonable to expect? The question is, what should we expect from the flag -print-multi-os-directory? If we take `man gcc` as authoritative, then I would read that as saying "you can expect gcc to return . or ../lib on non-multilib systems". @musl is a non-multilibe system. Is it reasonable for us to expect `gcc -print-multi-os-directory` to return ". or ../lib"? So yes, that should be the end state. > > > It ought to be possible to build gcc with that behavior on a musl system, > > either with a patch or without. Possibly we could just modify the eclass at > > setup_multilib_osdirnames() without any patch. > > Today musl has no multilib profiles. setup_multilib_osdirnames() tries hard > to be a no-op for such cases. > > Note that we do mangle MULTILIB_OSDIRNAMES only for ${SYMLINK_LIB} == "yes" > case. Gentoo's long term plan is to stop that and stick to upstream > definition of library locations. > > It looks like musl goes in the opposite direction. If @musl is to migrate, then we have to have some standard to which gcc and other compilers adhere to, else we'll just be migrating again when an upstream decides to change the standards. (In reply to Sergei Trofimovich from comment #28) > Also note that other tools assume matching layout. For example binutils does > the same lib/lib64 assumption: bintutils must have more intelligence than that. Incidentally, this is not just a musl issue. I looked at uclibc and it has been doing the same thing for years, even before I picked up its maintenance. So this is both a musl and uclibc issue.
> > Incidentally, this is not just a musl issue. I looked at uclibc and it has > been doing the same thing for years, even before I picked up its > maintenance. So this is both a musl and uclibc issue. I also just checked with alpine linux. They are also following the same "standard" as @musl gentoo for x86_64. Once again, I don't think @musl's expectations are unreasonable.
(In reply to Anthony Basile from comment #30) > > > > Incidentally, this is not just a musl issue. I looked at uclibc and it has > > been doing the same thing for years, even before I picked up its > > maintenance. So this is both a musl and uclibc issue. > > I also just checked with alpine linux. They are also following the same > "standard" as @musl gentoo for x86_64. Once again, I don't think @musl's > expectations are unreasonable. And I've also checked the output of `gcc -print-multi-os-directory` on alpine x86_64 and it gives the correct response `../lib`. At this point, I think this can be done by just editing `gcc/config/t-linux64` in the gcc source tree for musl and uclibc systems.
OK I spent some time discussing this with blueness. * We do *NOT* want to change the library directory, because a) "lib" is explicit requirement for musl, https://wiki.musl-libc.org/guidelines-for-distributions.html b) it is used already now, and other distros with musl are using it too c) "lib" makes sense for non-multilib * This means we need to find the best way to tell gcc about it and get a consistent output suitable for "lib" when building for a musl target. * The patch proposed by anarchy is only to be applied on a musl system. a) Conditional patching is bad. b) It fixes the problem only for amd64 (not arm64). c) It makes problems once you want to cross-build something *on* musl for a different system (since the compiler will use lib on *all* targets). d) It is non-upstreamable. * The patch proposed by slyfox can be applied everywhere. a) It forces non-multilib behaviour for any musl system, not just amd64 b) gcc -print-multi-os-directory returns . (which should be fine) c) Cross-building should work. d) The lib dir doesnt change (non-multilib requires "lib") e) Given that musl upstream requires "lib" explicitly everywhere (and is non-multilib), this could even go into upstream gcc f) Then it would even allow cross building *for* musl. Please check, and correct me if anything of this is wrong.
(In reply to Andreas K. Hüttel from comment #32) > OK I spent some time discussing this with blueness. Can you attach full chat log? > * We do *NOT* want to change the library directory, because > a) "lib" is explicit requirement for musl, > https://wiki.musl-libc.org/guidelines-for-distributions.html Do note: it only says about interpreter path to reside in /lib. It's ok to have /lib/ld.so -> /lib64/ld.so symlink. Rest of libraries don't have to live in /lib. gentoo/glibc ebuild for example creates symlinks into /lib/ when needed by ABI and installs the libraries into $(get_libdir). And I still believe lib64 is the proper location. It would also make multilib musl a no-brainer addition if an user desires such a setup. It would be exactly as glibc does it today. > b) it is used already now, and other distros with musl are using it too Do we have links to patches they apply and upstream discussion of upstreaming those? > c) "lib" makes sense for non-multilib If it would work - sure. Unfortunately it does not work for gcc as this bug shows. And I would argue it won't work unless explicitly changed in gcc and binutils upstream. This is a gcc behaviour change. > * This means we need to find the best way to tell gcc about it and get a > consistent output suitable for "lib" when building for a musl target. > > * The patch proposed by anarchy is only to be applied on a musl system. > a) Conditional patching is bad. > b) It fixes the problem only for amd64 (not arm64). > c) It makes problems once you want to cross-build something *on* musl for > a > different system (since the compiler will use lib on *all* targets). > d) It is non-upstreamable. > > * The patch proposed by slyfox can be applied everywhere. > a) It forces non-multilib behaviour for any musl system, not just amd64 > b) gcc -print-multi-os-directory returns . (which should be fine) > c) Cross-building should work. > d) The lib dir doesnt change (non-multilib requires "lib") > e) Given that musl upstream requires "lib" explicitly everywhere (and is > non-multilib), this could even go into upstream gcc > f) Then it would even allow cross building *for* musl. > > Please check, and correct me if anything of this is wrong.
(In reply to Anthony Basile from comment #29) > (In reply to Sergei Trofimovich from comment #27) > > > > But you are prepared to change upstream gcc to account for this use case? > > I'd like to see upstream gcc to be onboard with this plan. > > > > With respect, but this is disingenuous. A compile time switch could address > this, so yes, I'd like to see something like that upstream, but its unlikely > to happen easily. While "all this is software and we can change it" is true I don't see it as simple. > > AFAIU there are none. gcc implementation is the standard. > > This is a problem because there are other compilers. An implementation > can't de facto be a standard. You can propose one. Refining FHS might be a good place. > > > I'm not sure what you mean by 2b. > > > > [2a.] changes gentoo, [2b.] changes upstream gcc. > > > > > The end state is to have `gcc -print-multi-os-directory` behave as stated in > > > the man page for non-multilib systems. > > ... > > > I read this as saying that it should return either . or ../lib in our case. > > > > I read that musl@ does not plan to switch from /lib and wants /lib to be end > > state. Is that correct? > > Why are you framing this as an issue of what musl@ wants rather than what it > is reasonable to expect? The question is, what should we expect from the > flag -print-multi-os-directory? If we take `man gcc` as authoritative, then > I would read that as saying "you can expect gcc to return . or ../lib on > non-multilib systems". > > @musl is a non-multilibe system. Is it reasonable for us to expect `gcc > -print-multi-os-directory` to return ". or ../lib"? > > So yes, that should be the end state. I see. I don't read it like that. I'll send an email to gcc mailing list to clarify that detail in 2 weeks once I get back from vacation. That should settle the argument down. > > > It ought to be possible to build gcc with that behavior on a musl system, > > > either with a patch or without. Possibly we could just modify the eclass at > > > setup_multilib_osdirnames() without any patch. > > > > Today musl has no multilib profiles. setup_multilib_osdirnames() tries hard > > to be a no-op for such cases. > > > > Note that we do mangle MULTILIB_OSDIRNAMES only for ${SYMLINK_LIB} == "yes" > > case. Gentoo's long term plan is to stop that and stick to upstream > > definition of library locations. > > > > It looks like musl goes in the opposite direction. > > If @musl is to migrate, then we have to have some standard to which gcc and > other compilers adhere to, else we'll just be migrating again when an > upstream decides to change the standards. I agree. > (In reply to Sergei Trofimovich from comment #28) > > Also note that other tools assume matching layout. For example binutils does > > the same lib/lib64 assumption: > > bintutils must have more intelligence than that. > > > Incidentally, this is not just a musl issue. I looked at uclibc and it has > been doing the same thing for years, even before I picked up its > maintenance. So this is both a musl and uclibc issue. I'd suggest not to conflate the two issues unless we declare all libcs should be have the same behaviour (like glibc). Then it would be a larger undertaking.
(In reply to Sergei Trofimovich from comment #33) > > c) "lib" makes sense for non-multilib > > If it would work - sure. Unfortunately it does not work for gcc as this bug > shows. And I would argue it won't work unless explicitly changed in gcc and > binutils upstream. This is a gcc behaviour change. I'm not sure I understand what you mean here. If we decide to tell gcc "musl is always non-multilib", which is essentially done by your patch, then, as far as I understand it, `gcc -print-multi-os-directory` returns . (which is perfectly fine and solves the problem here).
I'm sorry Sergei, but we're not going to migrate amd64 or aarch64. I'm closing this bug and will simply maintain gcc for musl in the overlay. Unfortunately, this means musl will not be integrated into the tree.
I have opened a bug report upstream with slyfox's change to see if we can get it landed there.
(In reply to Jory A. Pratt from comment #37) > I have opened a bug report upstream with slyfox's change to see if we can > get it landed there. I'm continuing this bug at https://github.com/gentoo/musl/issues/233
(In reply to Andreas K. Hüttel from comment #35) > (In reply to Sergei Trofimovich from comment #33) > > > > c) "lib" makes sense for non-multilib > > > > If it would work - sure. Unfortunately it does not work for gcc as this bug > > shows. And I would argue it won't work unless explicitly changed in gcc and > > binutils upstream. This is a gcc behaviour change. > > I'm not sure I understand what you mean here. > > If we decide to tell gcc "musl is always non-multilib", which is essentially > done by your patch, then, as far as I understand it, `gcc > -print-multi-os-directory` returns . (which is perfectly fine and solves the > problem here). I expect at least binutils to require a similar fix. And probably other toolchains (clang?) and packages (gdb?). It would be an interesting exercise to find them all.
(In reply to Sergei Trofimovich from comment #39) > (In reply to Andreas K. Hüttel from comment #35) > > (In reply to Sergei Trofimovich from comment #33) > > > > > > c) "lib" makes sense for non-multilib > > > > > > If it would work - sure. Unfortunately it does not work for gcc as this bug > > > shows. And I would argue it won't work unless explicitly changed in gcc and > > > binutils upstream. This is a gcc behaviour change. > > > > I'm not sure I understand what you mean here. > > > > If we decide to tell gcc "musl is always non-multilib", which is essentially > > done by your patch, then, as far as I understand it, `gcc > > -print-multi-os-directory` returns . (which is perfectly fine and solves the > > problem here). > > I expect at least binutils to require a similar fix. And probably other > toolchains (clang?) and packages (gdb?). It would be an interesting exercise > to find them all. We are in good company with the other musl distributions.
> > If we decide to tell gcc "musl is always non-multilib", which is essentially > > done by your patch, then, as far as I understand it, `gcc > > -print-multi-os-directory` returns . (which is perfectly fine and solves the > > problem here). > > I expect at least binutils to require a similar fix. And probably other > toolchains (clang?) and packages (gdb?). It would be an interesting exercise > to find them all. What I dont understand - do you mean that they are all broken now? At least binutils seems to work fine on musl. Where does binutils set their libdir?
Status: RESOLVED → CONFIRMED I don't want to stifle discussion over this issue, but it has diverged from the original problem. I'm fixing that for musl on the overlay in conjunction with musl upstream and should have a fix by tomorrow. Do you want to take ownership of this bug?
As we got exolicit confirmation from musl upstream that /lib/ is preferred gcc will need a fix: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077#c2 toolchain@ is happy to take it. I suggest you to file a separate bug for uclibc to sort out the state there.
> > toolchain@ is happy to take it. > Thanks. I'll ping you when it lands upstream. Be aware that I am part of toolchain@ team. My point is that this is not a musl issue and musl@ has adopted a stop-gap solution until we can backport from upstream.
(In reply to Sergei Trofimovich from comment #43) > > I suggest you to file a separate bug for uclibc to sort out the state there. Right. uclibc has a different structure (including macros and configuration options) which lead to a different solution.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=26578a15abfca9149f296c33b754fa195e0ccf9b commit 26578a15abfca9149f296c33b754fa195e0ccf9b Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2020-03-27 23:47:15 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2020-03-27 23:54:41 +0000 multilib.eclass: multilib_env(): set LIBDIR=lib for *-musl* In contrast to glibc musl profiles use 'lib' layour for 32-bit and 64-bit targets. multilib_env() did not take it into account and assumed glibc's lib64 layout. That breaks crossdev as it uses multilib_env to extract target definition. Native builds are unaffected by this change. Bug: https://bugs.gentoo.org/675954 Bug: https://gcc.gnu.org/PR90077 Bug: https://github.com/gentoo/musl/issues/245 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/multilib.eclass | 13 ++++++++++++- eclass/tests/multilib.sh | 4 ++++ 2 files changed, 16 insertions(+), 1 deletion(-)
Having played a bit with gcc's ./configure arguments I found a way to convince gcc into using 'lib' without external patches by using '--disable-multilib --with-multilib-list=': # configure as: $ ../gcc/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-gentoo-linux-musl --disable-multilib --with-multilib-list= $ gcc/xgcc -B. -print-multi-os-directory . Seems to do the right thing (and surprisingly changes behaviour). Asked in gcc dev ML if we can rely on it: https://gcc.gnu.org/pipermail/gcc/2020-March/231981.html
looks like the link wrong or changed, here's the correct one. https://gcc.gnu.org/pipermail/gcc/2020-March/000218.html any conclusions so far? I either need to add pure64 patches to musl overlay gcc ebuilds, or can we just rely on '--disable-multilib --with-multilib-list=' on *-musl targets in the eclass? dropping gcc from musl overlay would be awesome, of course only if this solution works.
I meant pure64 ppc64 patches.
No, it will probably break for other arches.
(In reply to Sergei Trofimovich from comment #50) > No, it will probably break for other arches. The solution I'm proposing, but Sergei will not accept, is to apply a patch selectively.
Ok, let me get this straight - we're having an argument over adding lines vis the following, to accommodate upstream musl standards: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n345 https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n367 /8 or would we be better hacking: https://gitweb.gentoo.org/repo/gentoo.git/tree/eclass/toolchain.eclass#n660 to make the same modifications in a more agnostic fashion (unless I'm mistaken, this function performs similar hacks to the relevant files?) I'm not quite sure I'm seeing which set of ideological standards we are trying to adhere to here .. but it would be rather nice to find a Solution which doesn't require extensive hacks to work around? no?
(In reply to Georgy Yakovlev from comment #48) > just rely on '--disable-multilib --with-multilib-list=' on *-musl targets in > the eclass? > If that works and is acceptable to Sergei, then let's do that.
I tested '--disable-multilib --with-multilib-list=' quickly (via EXTRA_ECONF to gcc) and it did not work for me as expected, but I may have screwed up something. I will run need another test on clean chroot to verify.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/musl.git/commit/?id=91544571441f85d7d5d13a3e8370e8cf9a93f29c commit 91544571441f85d7d5d13a3e8370e8cf9a93f29c Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2020-10-05 10:23:27 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2020-10-05 22:55:58 +0000 sys-devel/gcc: refresh gcc-pure64 patch amd64 and arm64 parts unchanged. moved the file and added ppc64 stuff, based on alpine patch. this is final showstopper before enabling ppc64/ppc64le catalyst builds. Bug: https://bugs.gentoo.org/675954 Issue: https://github.com/gentoo/musl/issues/233 Tracker: https://github.com/gentoo/musl/issues/295 Closes: https://github.com/gentoo/musl/pull/350 Package-Manager: Portage-3.0.8, Repoman-3.0.1 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> sys-devel/gcc/files/8.3.0/gcc-pure64.patch | 25 --------- sys-devel/gcc/files/9.3.0/gcc-pure64.patch | 86 ++++++++++++++++++++++++++++++ sys-devel/gcc/gcc-10.1.0-r1.ebuild | 2 +- sys-devel/gcc/gcc-10.2.0-r1.ebuild | 2 +- sys-devel/gcc/gcc-9.3.0-r1.ebuild | 2 +- 5 files changed, 89 insertions(+), 28 deletions(-)
Created attachment 722098 [details, diff] 0001-musl-always-use-lib-directory-for-all-x86_64-ABIs-PR.patch How about something mechanical like 0001-musl-always-use-lib-directory-for-all-x86_64-ABIs-PR.patch.
(In reply to Sergei Trofimovich from comment #56) > Created attachment 722098 [details, diff] [details, diff] > 0001-musl-always-use-lib-directory-for-all-x86_64-ABIs-PR.patch > > How about something mechanical like > 0001-musl-always-use-lib-directory-for-all-x86_64-ABIs-PR.patch. I didn't test the patch, but that looks good to me.
ppc64 also needs it, and arm64 here's the match musl overlay applies https://github.com/gentoo/musl/blob/master/sys-devel/gcc/files/9.3.0/gcc-pure64.patch
(In reply to Georgy Yakovlev from comment #58) > ppc64 also needs it, and arm64 > > here's the match musl overlay applies > > https://github.com/gentoo/musl/blob/master/sys-devel/gcc/files/9.3.0/gcc- > pure64.patch The plan is to apply the equivalent to all t-linux64 targets, which is: gcc/config/i386/t-linux64 gcc/config/mips/t-linux64 gcc/config/rs6000/t-linux64 gcc/config/s390/t-linux64 gcc/config/sparc/t-linux64 I'd like to get ACK from upstream before spending more time on it.
(In reply to Sergei Trofimovich from comment #59) > (In reply to Georgy Yakovlev from comment #58) > > ppc64 also needs it, and arm64 > > > > here's the match musl overlay applies > > > > https://github.com/gentoo/musl/blob/master/sys-devel/gcc/files/9.3.0/gcc- > > pure64.patch > > The plan is to apply the equivalent to all t-linux64 targets, which is: > > gcc/config/i386/t-linux64 > gcc/config/mips/t-linux64 > gcc/config/rs6000/t-linux64 > gcc/config/s390/t-linux64 > gcc/config/sparc/t-linux64 > > I'd like to get ACK from upstream before spending more time on it. nice! thanks for doing it. I hope a day comes when we drop gcc from musl overlay.
