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


   Date: Mon, 10 Jul 2000 16:15:28 -0700
   From: "H . J . Lu" <hjl@valinux.com>

   On Mon, Jul 10, 2000 at 03:34:40PM -0700, Richard Henderson wrote:
   > We need to get glibc out of the business of providing libgcc
   > functions.  The best long-term way to do that, IMO, is once

   glibc shouldn't provide any libgcc functions. However, glibc will
   use some libgcc functions. That means libgcc.so has to be available
   when libc.so is loaded. I only proprose to let glibc decide where to
   put libgcc.so. gcc only provides a libgcc.a compiled with -fPIC and
   maybe a script like build-libgcc.so which will build libgcc.so from
   libgcc.a. Glibc will build libgcc.so from libgcc.a in gcc and install
   it at an appropriate place.

This isn't necessary at all.  The shared libgcc belongs in /lib.  If
the GCC folks do their job properly, and take care of backwards
compatibility issues, installing GCC can simply upgrade it if the
version provided with the new GCC has the highest "version number".

Lettenig glibc build libgcc.so from an archive installed by GCC is
pointless and only puts limits on one's possibilities to use nice
hacks.

Mark

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