Re: GCC 3.0 Release Criteria

[Richard Henderson <rth at cygnus dot com>]

On Sun, Apr 30, 2000 at 06:55:13PM -0400, David Edelsohn wrote:
> 	When you propose making libgcc a shared library on many systems,
> do you mean GNU/Linux and other open source operating systems, or are you
> referring to most commercial operating systems as well?

I'm referring to most everyone.

> For an application linked against a libgcc shared library to be
> transportable to other systems, either a copy of the libgcc shared
> library needs to be present on those other systems or the application
> needs to be linked statically.

Yes.  Though...

> If the operating system has its own shared libraries which will be
> present on the other systems, statically linking will include the
> systems native libraries as well.  Linking all libraries statically can
> cause numerous problems -- not just executable size.

... I'm operating under the belief that individual libraries
can be linked statically on such systems.  Under Solaris or with
gnu ld one would do

	ld ... stuff ... -Bstatic -lgcc -Bdynamic -lc

If this is not the case on some system, we could perhaps call the
two libraries libgcc.so and libgcc_static.a or something.

The point being that would would not have to link *everything*
statically.

> 	libgcc is a fundamental support library for GCC.  If one is not
> linking any other GCC-provided libraries (e.g., libstdc++) as a shared
> library, I am concerned about catching a programmer by surprise that
> libgcc needs to be installed everywhere or the only other option is static
> linking.

Perhaps, but that is a very visible sort of failure with an obviously
deducable cause, and for the most part an equally obvious solution.

The alternative, when a programmer starts creating shared libraries
of their own, is silent failures of a sort that are difficult for us
to clearly explain, much less for them to diagnose.

I would like to think we're choosing the lesser of two evils, but
clearly opinions are going to vary.

--

Thinking about this some more, perhaps we could come to a compromise.

  (1) When linking a shared library (i.e. gcc -shared) we link 
      against the shared libgcc.so.  This ensures that the newly
      created library does not accidentally include libgcc symbols
      and re-export them.

  (2) When linking an executable, we examine (in collect) all of
      the referenced shared libraries and see if they reference
      libgcc.so.  If so, we link the main application against
      libgcc.so as well, otherwise against the static version.

In this way we do not add a reference to libgcc.so if we did not
have one before.  Note that this does not catch all cases:

  (a) One of the libraries against which the program is linked, 
      directly or indirectly, gets replaced with a version that
      does reference libgcc.so.

  (b) dlopen is used to load libraries at runtime that reference
      libgcc.so.

However this may well be a 90% solution.  With gcc command-line
options to force one or the other, this may be good enough.

Problem (a) may be mitigated by restricting the libgcc.so suppression
to libraries from system directories.  I.e. referencing /lib/libc.so
on Solaris doesn't trigger a link against a shared libgcc, but referencing
/usr/local/lib/libfrobnitz.so does.  This under the assumption that
the user will not be recompiling that to which they have no sources,
and that they probably built libfrobnitz themselves, and may well
upgrade it to version 2.0 next week.

Problem (b) may be mitigated by forcing a link against shared libgcc
whenever -ldl is used.

When it finally occurrs that one of the open source systems link libc
against shared libgcc, then we'll always find a reference, and so use
the shared libgcc any time the link is not fully static.

Thoughts?


r~