Re: What to put in a shared libgcc

[Jeffrey A Law <law at cygnus dot 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.

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.

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.
jeff