This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Try to solve shared libgcc and glibc
- To: "H . J . Lu" <hjl at lucon dot org>
- Subject: Re: Try to solve shared libgcc and glibc
- From: Mark Kettenis <kettenis at science dot uva dot nl>
- Date: 23 Mar 2001 12:37:36 +0100
- Cc: GNU C Library <libc-alpha at sourceware dot cygnus dot com>
- References: <20010322115912.A14625@lucon.org>
"H . J . Lu" <hjl@lucon.org> writes:
> I am trying to address an issue with shared libgcc and glibc. I can
> understand the need for shared libgcc from gcc. But I don't think
> the current scheme will work for glibc. I propose the system based
> on glibc also provides the shared libgcc as a system library. It is
> trivial to build our own libgcc_s.so.0 during the glibc build. We
> provide libgcc_s.so as
>
> # cat << EOF > /usr/lib/libgcc_s.so
> GROUP (
> /lib/libgcc_s.so.0
> -lgcc
> )
> EOF
Comments:
1. This doesn't address the problem with shared libraries re-exporting
symbols from libgcc.a.
2. This means that one has to rebuild glibc whenever stuff is added to
libgcc.
> We then make libgcc_s.so.0 an auxiliary filter for libc.so. I enclosed
> a demo here:
Richard Henderson anticipated just the opposite: Make libc.so an
auxiliary filter for libgcc_s.so, such that the libgcc functionality
that's currently included in libc.so becomes a "servicable component".
It really is a shame that Ulrich keeps ignoring the problem. Your
rants and patches really don't help if you don't explain *why* they're
necessary and *how* they work.
Mark