This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Updating multilib support after a compiler is built
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Jon Beniston <jon at beniston dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Tue, 18 May 2010 18:54:17 +0000 (UTC)
- Subject: Re: Updating multilib support after a compiler is built
- References: <001601caf6af$c597f3a0$50c7dae0$@beniston.com>
On Tue, 18 May 2010, Jon Beniston wrote:
> Hi,
>
> Is it possible to update the multilib combinations supported by GCC after it
> has been built? (I would like to build some libraries optimised for
> different CPUs variants, that aren't built by default).
>
> I tried doing this via a specs file, but something like the following fails:
Even if you get modifications of specs to work (and some pieces such as
--with-arch configuration are handled in different ways that may not be
configurable that way), GCC's own libraries are nontrivial to build
outside of building GCC itself - especially libgcc (libstdc++ is easier).
The libgcc configuration uses information passed from the gcc/ directory
because the toplevel libgcc transition is incomplete, including target
macros from tm.h which is mainly a host header but also used for some
things on the target. I certainly encourage cleaning up these things so
that the libgcc build configuration can be properly contained within the
libgcc/ directory and not depend on host tm.h headers.
http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration
If you only want to optimize some libraries but not others, GCC doesn't
effectively support different multilibs having different sets of libraries
either. My proposal <http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html>
would have the effect of making it much easier to have different sets of
libraries for each multilib.
--
Joseph S. Myers
joseph@codesourcery.com