Re: Why link C with crtstuff? [patch]

[Sergei Ivanov <svivanov@pdmi.ras.ru>]

Sorry if this is a double posting. Something went wrong at the first attempt.

> > No @@ here, patch (2.4) just skips this.
> 
> Ooops. Here is the new one.
> 
> > Also, it seems to be against a snapshot (there is no s-crtS in 1.0.2).
> 
> It is stamp-crtS in 1.0.2. Just apply it by hand for 1.0.2.

It works, in a sense that it does not statically link frame.o to main(){},
and a recompiled shared library has __register_frame_info etc,
so it does not break existing binaries.

Still it is unpleasant that the binary appears dependent on these
symbols if linked with the library (and now with weak symbols even 
an extra -lgcc does not help).

Maybe use different names for static and shared things?  For example,
let some __register_frame_info__static in libgcc be a copy/alias/call to
__register_frame_info and let crtbegin.o have this new symbol weak extern
while crtbeginS.o uses __register_frame_info.

A side note: dependence on gcc internals from shared libs it not only
a problem of compatibility between gcc versions. A library could be
rewritten/optimized so that it stops using a certain gcc internal
so that it disappears. The author would normally change only a minor
version, but in this case the library becomes incompatible.

Sergei