LIBGCC_SPEC

[Jim Wilson]

Matt Austern wrote:
> Unfortunately, this comment is no longer true.  A target can indeed 
> define LIBGCC_SPEC, but that definition is no longer used.  Instead, the 
> LIBGCC_SPEC is munged by a function called init_gcc_specs.  There 
> doesn't seem to be any way of turning the munging off (short of 
> disabling shared libgcc entirely), which means that targets where the 
> munged spec string is inappropriate are just out of luck.

This seems a little confused.  LIBGCC_SPEC is used as intended, and then 
it is munged in order to support some target independent features, such 
as handling shared libgcc related options.

You neglected to mention why the munging is incorrect for your target. 
Maybe it can be fixed?

Incidentally, all of this munging is inside ENABLE_SHARED_LIBGCC ifdefs. 
If you don't want the shared libgcc support, then you can get rid of the 
  munging by ensuring that ENABLE_SHARED_LIBGCC is not defined.

> define LIBGCC_SPEC explicitly.  This will break targets that explicitly 
> define nondefault LIBGCC_SPEC and rely on the munging.  Are there any 
> such targets?

I think most targets that define LIBGCC_SPEC fall in this category.

> 2. Along the same lines but less drastic: still do the munging in the 
> preprocessor and allow a target to define REAL_LIBGCC_SPEC, which will 
> get used instead of the munged LIBGCC_SPEC if it exists.

This breaks support for some of the shared libgcc related options.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com