This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Updating multilib support after a compiler is built


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]