This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


   From: Alexandre Oliva <aoliva@redhat.com>
   Date: 13 Jul 2000 18:35:37 -0300

   On Jul 11, 2000, Alexandre Oliva <aoliva@redhat.com> wrote:

   > Why, then, should glibc people take over the creation of this shared
   > library for GNU/Linux systems?

   Now here's one additional, interesting problem.  Assume libgcc is a
   shared library.  It has obviously been linked with some version of
   libc, given that it uses symbols from libc.  This means it will have a
   dependency on some particular libc SONAME encoded in it.

That isn't necessary per se.  You can have undefined references in a
shared library.

   Now think of glibc: since it uses libgcc, it will also have some
   particular libgcc SONAME encoded in it.  But libgcc already depended
   on libc, so we have a circularity.  No big deal: each library will
   only be loaded once, and everything is fine, right?  Despite the minor
   problem of how to bootstrap this situation.

The bootstrapping problem is solvable with DT_AUXILIARY.  If libc
contains a DT_AUXILIARY entry for libgcc, instead of an ordinary
dependency (DT_NEEDED), libc will only use libgcc if it does exist.
This means that libc itself would still have to contain copies of the
stuff from libgcc that it explicitly exports now, but these could
become dummy versions in the long run.

   But there's a major problem too.  What if I decide to upgrade one of
   GCC or glibc.  What now?  New programs I create will depend on the
   most recent libgcc and glibc, but one of the libraries (the one that
   was not updated) will depend on the older version of the other.  So,
   if I had upgraded GCC, I'd have two different, potentially
   incompatible versions, of libgcc loaded into the same process.  I'm
   afraid this may not work.

That's why the initial message on the gcc lists where the GCC
devlopers announced their intention to turn libgcc into a shared
library worried me so much.  The current libgcc.a contains some stuff
that IMHO isn't suitable to put into the shared libgcc.

Tightly controlling the libgcc.so ABI is extremely important.  The
SONAME of libgcc can *never* change (at least not without changing the
libc SONAME too) on Linux and the Hurd.  On the bright side these
systems use the complete GNU toolchain which means that we have a lot
more tools to avoid this than other platforms.

This discussion has far too much focussed on the question who'll have
to build the shared libgcc.  And that part of the discussion hasn't
been terribly productive.  And actually building a shared libgcc
*before* the GCC team is committed to mainting binary compatibility of
the stuff we're going to put into it is pointless.

Instead I'd like to start working with the GCC team on establishing an
ABI for that shared libgcc.  I could sure use some assistence on that
from GCC developers interested in Linux.

Mark

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]