https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111065
Jeffrey A. Law <law at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Assignee|unassigned at gcc dot gnu.org |kito at gcc dot gnu.org
Resolution|--- |WONTFIX
Blocks|120763 |
--- Comment #8 from Jeffrey A. Law <law at gcc dot gnu.org> ---
Multilibs for the native toolchains and multilibs for embedded toolchains are
inherently different in their use model, on-disk layout, etc.
For the native toolchains the set of multilibs is primarily driven by distro
needs and their on-disk layout is driven by the C library, which is primarily
glibc. We typically have a fairly small subset of multilibs for the native
toolchain case. The assumption is if you're targetting anything nonstandard,
then you're responsible for making sure all the components are built in the
appropriate way.
In the embedded space we try to have a much more extensive of multilibs as
that's what's needed to be competitive in that world. It's also the case that
newlib is better set up for those extensive multilib setups than glibc.
Anyway, ultimately I think this is a misunderstanding of how multilibs work,
particularly on the native side.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120763
[Bug 120763] [meta-bug] Tracker for bugs to visit during weekly RISC-V meeting
