RE: Updating multilib support after a compiler is built

Thanks for the suggestions. > 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 > would have the effect of making it much easie

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,

Re: Updating multilib support after a compiler is built

"Jon Beniston" writes: > Is it possible to update the multilib combinations supported by GCC after it > has been built? I believe that all the multilib information can be read from the specs file, so, technically, yes. > %rename multilib_matches old_multilib_matches > *multilib_matches: > mcpu

Re: Updating multilib support after a compiler is built

On Tue, 2010-05-18 at 18:30 +0100, Jon Beniston wrote: > Is it possible to update the multilib combinations supported by GCC after it > has been built? I don't know for sure, but I would guess and imagine that it is not possible. The intuition is that multilib-ness is really a matter of choosin

Updating multilib support after a compiler is built

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: %rename multil