This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] MULTILIB_COMPATIBLE option support in multilib
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ilya Enkovich <enkovich dot gnu at gmail dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>, Terry Guo <terry dot guo at arm dot com>
- Date: Thu, 22 Aug 2013 17:13:09 +0000
- Subject: Re: [RFC] MULTILIB_COMPATIBLE option support in multilib
- References: <CAMbmDYZPPSJUkEQxzoA29OFMopEnaUipFsvxPwDZoinCWz_Lcg at mail dot gmail dot com>
On Tue, 13 Aug 2013, Ilya Enkovich wrote:
> Any comments on the used approach?
You don't have any documentation (fragments.texi) in your patch. Apart
from that, this patch doesn't appear to do anything to engage with all the
problems of having multiple multilibs in use at once, such as the
inability of ld to handle multiple sysroots (so the single sysroot
determined by SYSROOT_SUFFIX_SPEC would just get quietly used), and the
need to get all search paths for one multilib (for libraries, and,
separately, for headers) used before any paths for another - those paths
may be accumulated from multiple specs rather than just a single spec, so
I don't think anything just locally changing how specs are processed can
suffice.
Certainly a much more detailed analysis of all the search paths that are
related to a multilib in some way, and how the driver causes the linker
and cc1 to search in those paths, and how multiple relevant options get
processed by the linker and cc1 after being passed to them, would be
needed to justify that a particular patch does achieve the desired search
order.
--
Joseph S. Myers
joseph@codesourcery.com