This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: DRIVER_SELF_SPECS and multilib
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: gnubie gnubie <gcc dot gnubie at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 04 Dec 2012 19:31:33 +0000
- Subject: Re: DRIVER_SELF_SPECS and multilib
- References: <CAJxfJa8MYejquXDd2qAA4bZ7FWkigMqyR_09CCchxJeVZuRaAA@mail.gmail.com>
gnubie gnubie <gcc.gnubie@gmail.com> writes:
> Hi,
>
> I notice that if you add a DRIVER_SELF_SPEC option and then add that
> option as a MULTILIB_OPTION, it doesn't build certain libraries for
> that multilib variant.
>
> for example, if you add:
>
> "%{mtestoption:-mcpu=cortex-a5 %<mtestoption}"
>
> (and then define mtestoption in the opt file)
>
> then add mtestoption as a multilib variant, it builds some of the
> libraries for that variant but not others. notable missing libraries
> being:
>
> libstdc++, libssp and libsupc++.
>
> most of the others are there. If you just add cortex-a5 as the
> variant then it works fine.
>
> Is this by design?
Kind-of. It's certainly by design that DRIVER_SELF_SPECS are applied
before multilib selection, because one of DRIVER_SELF_SPEC's main uses
is to infer an explicit multilib option from other non-multilib options.
The %<mtestoption in the spec above means that mtestoption won't ever be
involved in multilib selection.
I don't know why some libraries are behaving differently from others though.
On the face of it, plain:
"%{mtestoption:-mcpu=cortex-a5 %<mtestoption}"
ought to be OK. mtestoption will get passed down the cc1 etc., but
adding it to the .opt file should mean that it is accepted and ignored.
Richard