Re: What to put in a shared libgcc

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

   Date: Tue, 11 Jul 2000 17:12:35 -0600
   From: Jeffrey A Law <law@cygnus.com>

     In message <200007111759.e6BHxfp26885@delius.kettenis.local>you write:
     > [Sorry folks, tried to send this to gcc@gnu.org instead of
     > gcc@gcc.gnu.org :-(]
     > 
     > Here's an analysis of the modules in libgcc.a for GCC 2.95.2 on
     > i586-pc-linux-gnu.  Feel free to put this up on the gcc web pages if
     > you like (linked to the libgcc.so discussion page or so).
     > 
     > Based on this analysis, I think the only stuff that should be moved
     > into a shared libgcc on Linux/x86 is the frame registration stuff
     > (frame.o) and probably parts of the language-independent exception
     > handling stuff (libgcc.2[L_eh], i.e. the stuff that ends up in _eh.o).
   Actually, I *strongly* disagree with any notion that the contents of the
   two libraries should be different.

   Every major unix vendor has done this at some point in the last 10
   years, and every time it's caused problems.  Please, let's not make
   the same mistakes everyone else did, instead let's learn from them.

   The interfaces provided by the libraries need to be identical,
   anything else just makes life a living hell for application
   developers as well as tool developers.

We've been doing it with glibc quite successfully.  A typical Linux
installation has

  /usr/lib/libc.a
  /usr/lib/libc_nonshared.a
  /usr/lib/libc.so
  /lib/libc.so.6

where /usr/lib/libc.so is the following linker script:

  /* GNU ld script
     Use the shared library, but some functions are only in
     the static library, so try that secondarily.  */
  GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

It works quite well (although from time to time someone manages to
replace the libc.so linker scrypt with a symlink to /lib/libc.so,
usually with the help of an old version of that braindamaged tool
called ldconfig).

Of course not all linkers support this nifty trick, and we can't force
evrybody to use GNU ld :-(.

   Now I am open to the idea that there's libgcc.{a,so} that has some
   set of routines and some other library that has additional
   routines.  However, you have to be very careful about the things
   you do not include in libgcc -- for example the EH routines, which
   are the root of most of our recent problems.

I'm not sure I understand what you're saying here.  Do you mean
libgcc.a or libgcc.so (or whatever it's called).  I'd say that you
should be very careful about what you *do* put in a shared library.
There are parts in the current libgcc.a for which it would be very
unwise to put them into the shared libgcc.so.  If you want the
contents of every lib*.so paralleled by a lib*.a, this would imply
that you'd put all functions that don't go into libgcc.so will be
moved to libgcc2.a (or whetever it'll be called).

   We can't do self-contained libraries that include copies of those routines,
   it simply doesn't work.  Instead we need libraries which reference libgcc.so
   (or whatever it's called) to get those routines.

Indeed.  The EH stuff is the minimal stuff that should go into the
shared library we're talking about in these discussions here.

Mark