[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 --- Comment #6 from Sergei Trofimovich --- Not actively working on it. A bit of discussion from #gcc: 21:41:59 < pinskia> note your patch is incorrect 21:42:10 < trofi_> yup 21:42:13 < pinskia> it should just not add t-linux64 for musl 21:42:31 < trofi_> There is a bot of discussion at https://gcc.gnu.org/pipermail/gcc/2020-March/000218.html 21:42:43 < trofi_> https://gcc.gnu.org/pipermail/gcc/2020-March/000220.html 21:43:17 < trofi_> i think it means that debian's multiarch effectively forces use of t-linux64 21:43:28 < pinskia> right but musl does not support multiarch either 21:44:10 < trofi_> hm, then just dropping it might be good enough
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 John Doe changed: What|Removed |Added CC||bau2wux4sh at pkv73 dot anonbox.ne ||t --- Comment #5 from John Doe --- *** Bug 103889 has been marked as a duplicate of this bug. ***
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #4 from Sergei Trofimovich --- Sent https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574482.html for review.
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Sergei Trofimovich changed: What|Removed |Added CC||slyfox at inbox dot ru --- Comment #3 from Sergei Trofimovich --- Asked gcc mailing list what interaction we do expect with configure options --disable-multilib/--with-multilib-list= and out put of 'gcc -print-multi-os-directory' as: https://gcc.gnu.org/pipermail/gcc/2020-March/231981.html
[Bug target/90077] musl has no multlib support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90077 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #2 from Rich Felker --- musl does not support sharing an include dir between archs (or 32-/64-bit "versions of the same target" in gcc multilib framing), so aside from policy of not using lib names like lib64, the multilib framework is just not suitable. We do support full multiarch with separate include and lib paths for each separate arch/ABI in the same filesystem, similar but not exactly the same as what Debian does (Debian shares top-level include just not sys and bits; for musl this may unofficially work but it's not officially supported and there's no reason to believe it's compatible with 3rd-party libs that may install arch-dependent headers generated at build time into that dir).
