Re: GCC vs GLIBC: why this stance, Drepper ?!?

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Sun, 01 Jul 2001 13:46:12 -0700

   > It is the same thing as you are saying you can install another version
   > of the system shared C library, libc.so, in /usr/local/lib and expect
   > the whole machine will work reliably.

   Yes, I am saying that.  Isn't that true?  I didn't think the base
   system, installed by the vendor, was supposed to even know that /usr/local
   exists.  Now, users who put /usr/local in their PATH/LD_LIBRARY_PATH
   might get hosed -- but the system administrator shouldn't install stuff
   that doesn't work.

   Certainly, if the libc in /usr/local is backwards-compatible with the old
   one, then this should not be an issue.  And, our promise is that libgcc
   will be backwards compatible -- or we will bump the version number.  In
   either case, people will be OK when they install a new compiler.

Don't mention bumping the version number.  Some people get really
scared when you talk about that.

Anyhow, suppose you're on a system that uses GCC as its system
compiler, with libgcc_s.so.1 in /lib or /usr/lib.  Now suppose that
the system administrator installs a new version of GCC in /usr/local,
and that this version of GCC comes with a libgcc_s.so.1 that is
backwards compatible, but not quite forwards compatibles.  Support for
some new DWARF2 opcodes generated by the new GCC would be a good
example.

People start using the new compiler, but don't set RPATH/RUNPATH
and/or LD_LIBRARY_PATH.  When they run their C++ programs, the old
libgcc_s.so.1 from the system compiler gets used and their C++
programs fail for some mysterious reason, perhaps with a segmentation
fault when it throws an exception.  The solution is simple.  Setting
LD_LIBRARY_PATH fixes the problem.  Upgrading the system libgcc_s.so.1
is another option.  But how do you detect this from a user's bug
report?

I'm not sure what can be done about this.  I don't think any of the
GCC developers has access to a crystal ball.  I hope this convinces
you that one has to treat libgcc_s.so.1 with extreme care.  And
perhaps it is possible to plan ahead and make things fail in an
obvious way if code compiled with a new GCC is used in conjunction
with an old libgcc_s.so.1.

   *If* the system vendor decides to combine libgcc and libc, then packages
   will have different link dependencies depending on whether they were
   compiled with the system vendor's compiler, or with the FSF GCC
   distribution.  That's a cost/benefit for the system vendor to weigh;
   it's not our problem.

I think many people will disagree with you on that.  I for one would
appreciate it if the GCC team would help to prevent such gratuitous
differences, since they tend to cause bugs that are hard to track
down.

   There really is nothing magic about libgcc, as opposed to libX, or
   libgtk, or whatever.  It's just a library.

By default every shared library is linked against the shared libgcc.
In that sense it is just as magical as libc

   So, besides agreeing that it's complicated, which we do, what exactly do
   you want us to do?  I would be happy to have patches that make it easier
   for system vendors to do the things they want to do, but I will not
   support patches that put us into the role of a system vendor.  We don't
   have the expertise, and our goal is to support many, many systems; if
   we include special magic for GNU/Linux, we should do it for other free
   OS's too, and maybe non-free ones, and that places an additional burden
   on us that I don't think we should bear.  As a relatively concrete
   bright-line, I would not support patches that only make sense when
   GCC is put in /usr; my concern includes only cases where the compiler
   is put in /usr/local.

As a Hurd developer, I tend to think that the FSF GCC team should be
in the role as the system vendor for GNU/Hurd ;-).  And as someone who
doesn't use a Linux distribution, I would appreciate it when

   ./configure --prefix=/usr
   make bootstrap
   make install

would replace my current GCC with a new one without too much hassle.
But I think it already does, despite what HJ says.

Mark