Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 675954 - sys-devel/gcc: `gcc -print-multi-os-directory` returns ../lib64 (should be ../lib or .) on 64-bit musl and uclibc systems
Summary: sys-devel/gcc: `gcc -print-multi-os-directory` returns ../lib64 (should be .....
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-21 01:21 UTC by hanetzer
Modified: 2020-10-05 22:56 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge.musl,5.08 KB, text/plain)
2019-01-22 20:00 UTC, hanetzer
Details
gcc-musl.patch (gcc-musl.patch,382 bytes, patch)
2019-01-26 20:41 UTC, Sergei Trofimovich
Details | Diff
drop lib64 for musl users (gcc-5.4.0-x86-lib64.patch,620 bytes, patch)
2019-04-10 17:14 UTC, Jory A. Pratt
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description hanetzer 2019-01-21 01:21:48 UTC
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.
Comment 1 Mike Gilbert gentoo-dev 2019-01-21 04:42:46 UTC
systemd does not support anything but glibc.
Comment 2 hanetzer 2019-01-21 15:29:16 UTC
(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.
Comment 3 Mike Gilbert gentoo-dev 2019-01-21 15:50:45 UTC
Let's mention that in the summary then.
Comment 4 Anthony Basile gentoo-dev 2019-01-21 21:46:34 UTC
(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.
Comment 5 Sergei Trofimovich gentoo-dev 2019-01-21 22:21:45 UTC
../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'.
Comment 6 hanetzer 2019-01-22 20:00:16 UTC
Created attachment 562520 [details]
emerge --info
Comment 7 hanetzer 2019-01-22 20:04:12 UTC
(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
Comment 8 Sergei Trofimovich gentoo-dev 2019-01-22 20:35:36 UTC
(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
Comment 9 Sergei Trofimovich gentoo-dev 2019-01-26 20:34:30 UTC
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 \
Comment 10 Sergei Trofimovich gentoo-dev 2019-01-26 20:40:27 UTC
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 :=
Comment 11 Sergei Trofimovich gentoo-dev 2019-01-26 20:41:32 UTC
Created attachment 562928 [details, diff]
gcc-musl.patch
Comment 12 Sergei Trofimovich gentoo-dev 2019-01-26 20:51:32 UTC
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.
Comment 13 hanetzer 2019-02-01 01:51:55 UTC
(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?
Comment 14 Sergei Trofimovich gentoo-dev 2019-02-01 07:35:08 UTC
(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.
Comment 15 hanetzer 2019-02-02 01:42:45 UTC
(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
Comment 16 Jory A. Pratt gentoo-dev 2019-04-10 17:14:31 UTC
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.
Comment 17 Sergei Trofimovich gentoo-dev 2019-04-10 18:35:27 UTC
(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.
Comment 18 Anthony Basile gentoo-dev 2019-04-11 12:42:15 UTC
(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* ]].
Comment 19 Sergei Trofimovich gentoo-dev 2019-04-11 13:56:02 UTC
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).
Comment 20 Anthony Basile gentoo-dev 2019-04-11 21:10:58 UTC
(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.
Comment 21 Sergei Trofimovich gentoo-dev 2019-04-11 22:40:33 UTC
(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.
Comment 22 Anthony Basile gentoo-dev 2019-04-11 23:25:13 UTC
(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.
Comment 23 Anthony Basile gentoo-dev 2019-04-11 23:30:33 UTC
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.
Comment 24 Sergei Trofimovich gentoo-dev 2019-04-11 23:54:37 UTC
(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.
Comment 25 Sergei Trofimovich gentoo-dev 2019-04-11 23:57:09 UTC
(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?)
Comment 26 Anthony Basile gentoo-dev 2019-04-12 00:34:42 UTC
(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.)
Comment 27 Sergei Trofimovich gentoo-dev 2019-04-12 07:49:00 UTC
(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.
Comment 28 Sergei Trofimovich gentoo-dev 2019-04-12 07:54:46 UTC
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;
Comment 29 Anthony Basile gentoo-dev 2019-04-12 11:54:39 UTC
(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.
Comment 30 Anthony Basile gentoo-dev 2019-04-12 12:14:44 UTC
> 
> 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.
Comment 31 Anthony Basile gentoo-dev 2019-04-12 12:39:16 UTC
(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.
Comment 32 Andreas K. Hüttel gentoo-dev 2019-04-12 20:35:28 UTC
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.
Comment 33 Sergei Trofimovich gentoo-dev 2019-04-12 21:16:42 UTC
(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.
Comment 34 Sergei Trofimovich gentoo-dev 2019-04-12 21:22:22 UTC
(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.
Comment 35 Andreas K. Hüttel gentoo-dev 2019-04-12 22:14:00 UTC
(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).
Comment 36 Anthony Basile gentoo-dev 2019-04-12 23:58:07 UTC
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.
Comment 37 Jory A. Pratt gentoo-dev 2019-04-13 01:57:09 UTC
I have opened a bug report upstream with slyfox's change to see if we can get it landed there.
Comment 38 Anthony Basile gentoo-dev 2019-04-13 02:47:10 UTC
(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
Comment 39 Sergei Trofimovich gentoo-dev 2019-04-13 07:23:56 UTC
(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.
Comment 40 Anthony Basile gentoo-dev 2019-04-13 09:51:44 UTC
(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.
Comment 41 Andreas K. Hüttel gentoo-dev 2019-04-13 15:49:23 UTC
> > 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?
Comment 42 Anthony Basile gentoo-dev 2019-04-13 17:48:40 UTC
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?
Comment 43 Sergei Trofimovich gentoo-dev 2019-04-14 06:53:24 UTC
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.
Comment 44 Anthony Basile gentoo-dev 2019-04-14 15:06:28 UTC
> 
> 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.
Comment 45 Anthony Basile gentoo-dev 2019-04-14 15:08:51 UTC
(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.
Comment 46 Larry the Git Cow gentoo-dev 2020-03-27 23:54:47 UTC
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(-)
Comment 47 Sergei Trofimovich gentoo-dev 2020-03-28 10:33:06 UTC
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
Comment 48 Georgy Yakovlev gentoo-dev 2020-10-05 06:33:00 UTC
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.
Comment 49 Georgy Yakovlev gentoo-dev 2020-10-05 06:33:30 UTC
I meant pure64  ppc64 patches.
Comment 50 Sergei Trofimovich gentoo-dev 2020-10-05 06:37:56 UTC
No, it will probably break for other arches.
Comment 51 Anthony Basile gentoo-dev 2020-10-05 11:26:48 UTC
(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.
Comment 52 Michael 'veremitz' Everitt 2020-10-05 12:32:44 UTC
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?
Comment 53 Anthony Basile gentoo-dev 2020-10-05 13:51:46 UTC
(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.
Comment 54 Georgy Yakovlev gentoo-dev 2020-10-05 15:10:56 UTC
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.
Comment 55 Larry the Git Cow gentoo-dev 2020-10-05 22:56:39 UTC
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(-)