sys-devel/gcc: gcc -print-multi-os-directory returns ../lib64 on 64-bit musl systems

[blueness]

This is a continuation of https://bugs.gentoo.org/675954.

[blueness]

I'm looking to incorporate https://git.alpinelinux.org/aports/tree/main/gcc/gcc-pure64.patch

[awilfox]

You'll also need the patch at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89587 for 32-bit PowerPC.

We (Adélie) backported it to GCC 8 at https://code.foxkit.us/adelie/packages/raw/eebc569/system/gcc/disable-multiarch-ppc32.patch if that helps.

[blueness]

@awilfox thanks. i'm going to test amd64 and aarch64 first since my ppc32 is not in the best stated.

[gyakovlev]

with new power profiles I also see it.

file /usr/bin/gcc
/usr/bin/gcc: symbolic link to /usr/powerpc64le-unknown-linux-musl/gcc-bin/9.2.0/gcc

 gcc -print-multi-os-directory
../lib64

I need to add ppc64 to the thingie here 923dace

[gyakovlev]

even after patching still does

gcc -print-multi-os-directory
../lib64

will need to investigate.

[mjeveritt]

@gyakovlev am I right in thinking we got this fixed/patched upstream in the end? Or at least is elsewhere in-train?
@blueness ^ also.

[blueness]

@mjeveritt upstream ignored the bug, as I expected. Real life has gotten in the way of me fixing stuff, but the person to speak to to get this moving upstream is nsz in the #musl channel on freenode.

Side note: I have to apologize to everyone, but I know this is an issue and what's there is a hack. I'm just overwhelmed with real life.

[gyakovlev]

my talos is down for maintenance till next week, but I think it still returns lib64 even with b116034 and I did not have time to investigate it yet.

[mjeveritt]

https://bugs.gentoo.org/show_bug.cgi?id=675954 was gaining some traction with @trofi I believe doing some testing ...

[mjeveritt]

See also https://gcc.gnu.org/pipermail/gcc/2020-March/231981.html for a partial-solution?

I will try to do some follow-up in #musl

[MaskRay]

I am just trying to make -L in clang -target $triple '-###' (replace $triple with the directory names under usr/lib/{gcc,gcc-cross}/) output follow gcc more closely... And I noticed that gcc -print-multi-os-directory output has significance.

Some findings:

Arch Linux gcc / Debian gcc / Debian aarch64-linux-gnu-gcc => ../lib

Arch aarch64-linux-gnu-gcc / manually built --disable-multilib gcc => ../lib64

So do we know the rule for ../lib vs ../lib64? I need something which can be codified in clang driver.

[gyakovlev]

@MaskRay musl always prefers /lib no matter the bitness, as multilib is kinda unsupported with it.

https://wiki.musl-libc.org/guidelines-for-distributions.html#Multilib/multi-arch

~~from above link
musl does not support sharing an include directory between archs (or 32-/64-bit “versions of the same target” in GCC multilib framing), and thus is not compatible with GCC-style multilib. It is recommended that distributions build GCC with multilib disabled, and use library directories named lib, not lib64 or lib32. Most importantly (see above) distributions should not change the dynamic linker location to /lib64 or anything else, since this breaks ABI.