search

gentoo / musl

[MIRROR] musl development overlay
https://gitweb.gentoo.org/proj/musl.git
99 stars 59 forks source link

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

Open blueness opened 5 years ago

blueness commented 5 years ago

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

blueness commented 5 years ago

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

awilfox commented 5 years ago

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 commented 5 years ago

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

gyakovlev commented 4 years ago

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 923dace4203bf4d94b18a9f98600280a15ca7d95

gyakovlev commented 4 years ago

even after patching still does 

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

will need to investigate.

mjeveritt commented 4 years ago

@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 commented 4 years ago

@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 commented 4 years ago

my talos is down for maintenance till next week, but I think it still returns lib64 even with https://github.com/gentoo/musl/commit/b1160342d9c386cb908381a21ba958f7f3428498 and I did not have time to investigate it yet.

mjeveritt commented 4 years ago

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

mjeveritt commented 4 years ago

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 commented 3 years ago

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 commented 3 years ago

@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.