LIBGCC_SPEC

[Matt Austern]

On Feb 17, 2004, at 4:18 PM, Jim Wilson wrote:

> On Tue, 2004-02-17 at 15:46, Matt Austern wrote:
>> In the case of Darwin, the biggest problem is that -static and
>> -static-libgcc need to do completely different things.
>
> You still haven't explained what the problem is.  You said the output
> needs to be different, but you did not say what the difference is, or
> why it needs to be different.  If this has been explained in another
> thread, then just pointing to the other thread is fine.  Otherwise, 
> this
> is still too abstract.

I don't think it should be surprising that -static and -static-libgcc
need to do different things on some systems: the documented
behavior of the two options is almost unrelated.  -static is the
opposite of -shared: it means not to produce a dynamic library.
  -static-libgcc doesn't affect code generation, but just means to
use the .a version of libgcc instead of the .so version.  It makes
no sense to combine -static with -shared-libgcc, but all three of
the other combinations make sense are potentially distinct.

On Darwin the default is for everything (including the .a version
of libgcc) to be compiled in a way that's appropriate for putting
in a dynamic library, so  -static needs to link in a special version
of libgcc.  It's a much more drastic option than -static-libgcc.

Again, I'd be surprised if Darwin was the only system where the
logic in the spec string created by init_gcc_spec is inappropriate.
To some extent this discussion has to be an abstract one, because
it's an abstract question: is there a proof that init_gcc_spec's
logic is appropriate on all systems for which libgcc might be
shared?

> Alternatively, offer a patch, and then we can see what changes you are
> suggesting, and then we might be able to offer useful comments.

I've already posted a patch to allow targets to override the default
version of LIBGCC_SPEC in a way that's immune to init_gcc_spec's
rewriting.

			--Matt