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] |
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] |