Re: A completely different approach to EH runtime

[Don Bashford <bashford at scripps dot edu>]

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.

Joe Buck (JB) writes:

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.

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

We are a research institute with a few hundred Unix machines,
including SGI, Sun, HP, DEC/Compaq, and a rapidly growing number of
Linux boxes.  I, and a small cult of other Gnu fans here, do
installations of Gnu software in an automounted directory /tsri/gnu,
visible to all these machines by setting prefix=/tsri/gnu and
exec-prefix=/tsri/gnu/${archosv}, where ${archosv} is i86Linux2,
or hppaHPUX10, etc.

Also, user accounts generally allow any user in the institute to log
onto almost any other machine, and their home directories are
automounted so as to be visible in such logins.  So if I compile
something on one linux machine and stow it in $HOME/bin.i86Linux2,
say, it is visible to me when I log into any other linux machine on
campus. 

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.

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?  In our institute, even users who
want to compile things can use the gcc we provide under /tsri/gnu.
Why should they be forced to have a native one too?

We've already had the experience of sometimes being forced into a
"lowest common demonitor" situation with respect to glibc:
Exectutables that are supposed to be run on all of the campus's linux
boxes sometimes need to built on the box oldest version of glibc.  I
wouldn't want to forced into an L.C.D. sitution w.r.t. gcc also.

Per Bothner (PB) writes:

PB> "H . J . Lu" <hjl@valinux.com> writes:
PB> 
PB> > Say I build a DSO, libfoo.so, with $prefix/bin/gcc. And I do
PB> > 
PB> >       handle = dlopen ("libfoo.so", ...);
PB> > 
PB> > from an executable, bar, built by /usr/bin/gcc. When I start bar,
PB> > /lib/libgcc_s.so is loaded into memory. Now when dlopen comes, which
PB> > libgcc_s.so should be used by libfoo.so? Since bar has already loaded
PB> > libgcc_s.so from /lib, it won't load $prefix/lib/libgcc_s.so. Now
PB> > libfoo.so is very upset unless /lib/libgcc_s.so is 100% compatible
PB> > with $prefix/lib/libgcc_s.so.
PB> 
PB> Yes, indeed.  But why are you worrying about this case?
PB> 
PB> There are two cases:
PB> (1) /lib/libgcc_s.so is compatible with $prefix/lib/libgcc_s.so,
PB> so no problem.  (This is of course what we're hoping for!)
PB> (2) /lib/libgcc_s.so is not compatible with $prefix/lib/libgcc_s.so.
PB> In that case, the problem is using /usr/bin/gcc to compile bar which
PB> is using a library compiled by an incompatible compiler.  Well, don't
PB> do that!

"Don't do that," could turn into a pretty tough stance in practice.
My real-life situation is that I develop a number-crunching library
written in C++ that I want to be able to load as a Python module.  In
this case, it's Python, not an app written by me, that does the
dlopen.  I may want to upgrade to gcc-3.x for my library development
to take advantage of the full-blown C++ language and stdlibc++.  But
the python on my native system (or the one maintained by our local
Python evangalist under, you guessed it, /tsri/python) was probably
compiled with an older compiler version.  Your "don't do that" seems
to demand that I do my own private re-install of Python, plus any
add-on modules that I intend to use at the same time as I'm using my
module.  Ouch!

-Don Bashford
Assoc. Prof.
The Scripps Research Institute
bashford at scripps dot edu