Re: What to put in a shared libgcc

[Jeffrey A Law <law at cygnus dot com>]

  In message <200007112358.e6BNwfL30003@delius.kettenis.local>you write:
  > 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 )
Interesting.  I wish other vendors's linkers had the same capability it
would have avoided quite a bit of pounding my head against the wall over
the years.

  > 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).
What I was talking about was having two libraries -- one which would be
the intrinsics and EH support code (call it libgcc), the other would be
stuff that is far less version sensitive like profiling support (call it
libblah).

There would be no intersection between the functions provided by those
libraries.

Then again, it doesn't change the fundamental issue of dealing with the 
reexporting of the EH symbol problem.  But it does cut down on the number
things provided by libgcc for which we have to track ABI changes so
closely.

jeff