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: The libgcc.so for glibc initiative


   Date: Wed, 12 Jul 2000 23:04:17 -0700
   From: "H . J . Lu" <hjl@lucon.org>

   Hi, Folks,

   Given the current libgcc.so situation, I'd like to start the libgcc.so
   for glibc project. The goals are

   1. Binary compatible with binaries linked with glibc 2.0, 2.1, 2.2 and
   above.
   2. Stand alone as well as glibc add-on.
   3. Can be used to upgrade libgcc.so from an installed gcc.
   4. Support glibc and glibc only.
   5. Support glibc 2.2 and above.
   6. Support gcc 2.96 and above.

   It can be hosted on sourceforge or under glibc like linuxthreads. Any
   comments?

There's nothing against experimenting with this, and using it as a
temporary solution util the libgcc.so thing settles down a bit.
However, presenting this somehow as thee official libgcc.so for glibc"
is completely stupid.  That would only piss of the GCC team, and since
it's essential that we work with the GCC team on this thing (since
they will still have control over the bits of code included in libgcc,
and hence control huge parts of the ABI) this wouldn't be a terrible
good idea.  In other words, there can be no stable libgcc.so ABI if
the GCC team doesn't agree on it.

If this ever does become the official libgcc.so for glibc thing

   6. Support gcc 2.96 and above.

should become

   6. Support gcc 3.0 and above.

Since we shouldn't officially support an unreleased version of GCC.
Of course we'll have a --i-really-want-to-use-and-experimental-gcc
option, that makes it possible to create a libgcc.so from an
experimental GCC (such as 2.96 right now) for testing purposes.

Mark

PS Personally I still think that the GCC team should do the
libgcc.so.  They control the interfaces.  If they cannot keep the
interfaces (reasonably) stable this whole thing is doomed anyway.
This really is a much greater challange than the simple technicalities
required for successfully building and installing the libgcc.so.

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