Re: My proposal for the libgcc runtime ABI (ia64 gcc/glibc is broken.)

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

   From: Joern Rennecke <amylaar@cygnus.co.uk>
   Date: Tue, 11 Jul 2000 01:52:47 +0100 (BST)

   Whoever the version number is bumped up for a target you have to use
   a number that is lager than the current libgcc2 number, and you have to
   update a comment next to the libgcc version number what the next number
   should be, unless there is already a larger number there.

   Or we could be lazy and use a major / minor number scheme for abi / libgcc2.

I think the version number scheme isn't really an issue.  People don't
seem to get that you cannot remove things from the ABI and/or replace
things in the ABI without causing severe binary compatibility problems
with shared libraries, especially on systems where libc depends on the
shared libgcc.

Suppose you had for a long time a libgcc.so.1, and built several
shared libraries with it.  Now introduce libgcc.so.2 (because you had
to break backwards compatibility for some reason) and start building
programs with it.  These programs cannot use the old shared libraries
since libgcc.so.1 and libgcc.so.2 would probably clash.  Now think of
libc as one of these old shared libraries, and realise that things are
hopelessly hosed.  Recompiling libc won't help in this case, since
that would mean you cannot use any old binaries at all.  This means
you'll have to bump libc's soname, which is something that people
really don't like.

The conclusion is that control over the libgcc.so ABI should be really
tight.  The less stuff it contains the better.

Mark