Re: rfc: limited shared libgcc widgetry

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

The patch includes

> + SHLIB_LIBS = -lc

> + SHLIB_LIBS = -lc

> + SHLIB_LIBS = -lc

How does this work when the soname of libc changes, users have binaries
linked against the old shared libc and a shared libgcc, and GCC is
upgraded, the new shared libgcc being built against the new libc?  (This
may apply to both systems where libc is built with GCC and those where it
isn't; but whereas on the latter the version of libgcc could be changed in
line with libc version changes and multiple copies of libgcc kept around,
on the former a reasonable system for source upgrades to new major
versions of libc is needed.)

> +   # C++ symbols (DMGL_GNU)

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.

Also:

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; (b) if it is configured with
--enable-shared?

-- 
Joseph S. Myers
jsm28@cam.ac.uk