Re: A completely different approach to EH runtime

[Joe Buck <jbuck at synopsys dot COM>]

Don Bashford writes:

> I've been reading this discussion on the list archive and I'm worried
> about how this dynamic libgcc thing will play out in a large
> installation.  Although I'm putting this as a response to things Joe
> Buck and Per Bothner have written, I don't want to point fingers it
> these guys in partuclar.

I'm perhaps less concerned about this issue than some others because,
as a C++ programmer, I'm used to the problem of making sure that the
correct version of libstdc++ is found.  To me, we already have a
shared system library.  Still, people are correct to raise it as an
issue to make sure that we solve it correctly, or tell people how to.

Anyway, I wrote:

> JB> Exactly!  In almost all cases, a user will be adding a newer gcc to
> JB> a distribution that provides an older one, or will be assisting with
> JB> testing gcc snapshots.  It will be much rarer for a user to install
> JB> an older gcc on a system that has a newer one.  It is only in this
> JB> rare case where there might be a problem with having missing functionality
> JB> in the "private" libgcc_s.so.  The solution can be as simple as just
> JB> not installing the older libgcc_s.so at all and let all code (both
> JB> that compiled by the old and by the new compiler) use the newer
> JB> libgcc_so.so that will live (presumably) in /lib.

Don:
> In a large multi-user, multi-host environment this might be such a
> rare case, and stranger things are possible, end even likely.

An alternative means of constraining the shared library path in an
extremely hybrid environment is to use wrapper scripts:

#! /bin/sh
export LD_LIBRARY_PATH=whatever
exec /path/to/real.app "$@"

> For Linux, we are faced with the peculiarity that Red Hat 7.0 was
> shipped with the so-called "gcc-2.96", but serious user/developers
> need a more stable compiler, so we install gcc-2.95.2 under
> exec-prefix=/tsri/gnu/i86Linux2 and encourage users to put
> /tsri/gnu/i86Linux2/bin in their PATH ahead of /usr/bin.  At the same
> time, many of the Linux boxes on campus are running Red Hat 6.x.  So
> we have, simultaneously, the cases of using a gcc which may be older
> or newer than the "native" gcc.  So as to JB's solution of nuking the
> dynamic libgcc under /tsri/gnu in our case, for those running on
> machine whose "native" gcc is older it should be nuked, but for those
> running on a machine with a newer native gcc the dynamic libgcc under
> /tsri/gnu should NOT be nuked.  But of course, it cannot be both nuked
> and not nuked.

My suggestion only applies in the case where the system provides a
libgcc_s.so that is newer than the one that the local compiler provides,
AND these are compatible in only one direction.  This situation cannot
occur until at least 3.1 is released, if then.  If we're lucky, it may
be years before this problem arises; even so, I haven't ducked the issue.

Still, the library most definitely CAN be "nuked and not nuked", because this
decision is made on a per-machine (actually, per-machine-flavor) basis.
On any given machine, either the system provides a newer libgcc_s.so, or
it does not.  If it does not, then the version from the non-system gcc is
needed.  If it does, then this version is not needed and could potentially
cause difficulties.

So, let's say that your network has a mixture of Debian 3.4 (bopeep)
and Red Hat 9 machines, and Debian provides gcc-3.0 and Red Hat provides
gcc-3.2-beta-RH, and you also have some SuSe 10.1 machines running gcc-3.1.
Let's say that we utterly fail at stability and we had to make a
change twice, once in 3.1 and once in the 3.2 snapshots that Red Hat
decided to release early.  Let's export /opt/gcc-3.1 to the world.
What we want to happen is that the gcc-3.2-beta-RH machines don't
get /opt/gcc-3.1/lib/libgcc_s.so, but the Debian "bopeep" machines
do.  For the SuSe machines we don't care, since it's the same file.
I think that this is manageable.  With some trickery with NFS and hard
links, a server can export two versions of /opt/gcc-3.1/lib, one with
and one without the libgcc_s.so, without much pain.

> And by the way, the fact that a dynamically linked gcc gives rise to
> this notion of a "native" libgcc raises other thorny issue.  Since
> every program, including ls, etc., will depend on libgcc, then
> essentially all packages depend on the gcc package.  But many Linux
> users have no desire to compile anything.  Why should they be forced
> to install gcc as a system program?

You don't understand how packaging works.  What is called gcc by us turns
into many packages when the Debian, Red Hat, or SuSe people get done with
it.  Currently, the base compiler, the C++ front end, the Fortran front
end, etc are all treated as separate packages.  libgcc_s.so would be its
own (very small) package.