Re: GCC 3.0 Release Criteria

[Richard Henderson <rth at cygnus dot com>]

On Thu, Apr 27, 2000 at 10:45:42AM -0400, Kaveh R. Ghazi wrote:
> Just to clarify, we are talking about installing libgcc.so in addition
> to libgcc.a because people may want to statically link, right?

Absolutely.

> So for shared libs, we couple the user's library with libgcc.so and
> with static links of binaries we link against libgcc.a.

Yes.

> What about dynamic links of binaries?  If I develop an app for solaris
> or on linux with a version of gcc newer than the system one, I want to
> link against libgcc.a but dynamically against libc to avoid having to
> distribute libgcc.so.  Will we (can we) make this the default behavior?

This is a sticky problem, and I think the answer is no.  Primarily,
how do you know that your libgcc is newer that your user's? 

For Solaris this is easier -- the system libraries do not use libgcc,
so it's relatively easy to create an application that does not have
multiple libgcc problems.  Assuming your application itself does not
make heavy use of dsos.  While I still think we should not make a
static link to libgcc.a the default, it's easy to do on the commandline.
We might even add a --static-libgcc option to help out.

For Linux (or anywhere else that uses gcc as the system compiler),
this is extremely hard.  Here libc.so _is_ linked against libgcc. 
Furthermore, it makes calls into the EH registration routines
(so that eg qsort works for c++), and so invokes the worst of the
multiple-libgcc nastiness.  If your application statically links
against libgcc, but dynamically links against libc, you risk the
application blowing up when the user rebuilds libc with gcc 3.5 to
get all the keen new optimizations.

Hopefully the various distributions will help us out here by making
libgcc it's own package.  Those distributing applications can 
distribute the version of libgcc they used, and if it's newer than
the one installed on the system then libgcc can be upgraded at the
same time.  If we've done our job maintaining the libgcc ABI, then
this will work.

This is nasty, but I believe unavoidable.



r~