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


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

Re: Try to solve shared libgcc and glibc


On Fri, Mar 23, 2001 at 08:51:43AM -0800, H . J . Lu wrote:
> On Fri, Mar 23, 2001 at 12:37:36PM +0100, Mark Kettenis wrote:
> > "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.
> 
> Are you talking about shared libraries linked with -lgcc_s or -lgcc? If 
> they are linked with -lgcc_s, it sholdn't happen. When it happens, that
> means we don't want it in /lib/libgcc_s.so.0. If they are linked with 
> -lgcc, it may be a problem. I am not sure if we can do anything about
> it except for relinking them with -lgcc_s.
> 

Assuming that the main problem is libstdc++.so re-exporting symbols from
libgcc, we can provide a speciall auxiliary filter for libstdc++.so so
that the real definitions will come from libgcc_s.so.0. But I think
we should just rebuild them instead.


H.J.


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