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: LIBGCC_SPEC


Jim Wilson <wilson@specifixinc.com> writes:

> 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.

The problem is that these features are not truly target independent,
because they depend on the details of LIBGCC_SPEC.

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

You would end up writing a routine which had only one possible input,
Darwin's LIBGCC_SPEC, and only one possible output, the proposed
REAL_LIBGCC_SPEC.  You might as well just code it as

if (strcmp (LIBGCC_SPEC, "...") == 0)
  return "...";

which seems pointless.

> 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.

The purpose of this change is to get shared libgcc support working on
Darwin, so this would not be helpful.

-- 
- Geoffrey Keating <geoffk@geoffk.org>


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