Re: rfc: limited shared libgcc widgetry

[Richard Henderson <rth at cygnus dot com>]

On Tue, Sep 26, 2000 at 04:53:14PM +0100, Joseph S. Myers wrote:
> How does this work when the soname of libc changes, users have binaries
> linked against the old shared libc ...

The same horrible way that any libc upgrade works.  You're
trying to make the pain too complicated.

> If libgcc will include symbols that require the C++ compiler to be built,
> then shared libgcc should probably be disabled if --enable-languages is
> used to disable the C++ compiler; I don't think the symbols contained in
> a shared libgcc should depend on the languages chosen as that would be a
> recipe for incompatibilities.

Reasonable.  The main reason for needing a shared libgcc in the
first place is exception handling.

> If a system has a shared libgcc as a system library, and a user builds
> their own more recent GCC and installs it in a private directory, will
> programs built with that GCC use the symbols from its libgcc rather than
> the older system shared libgcc (a) if the private copy of GCC is
> configured with --disable-shared;

I suppose so, since the gcc driver would have to know that there
was no shared libgcc to link against, so it wouldn't have tried.

> (b) if it is configured with --enable-shared?

That's going to depend on the user's LD_LIBRARY_PATH.  I don't
like the notion of gcc automatically adding an rpath; that's just
a recipe for pain.



r~