Re: Try to solve shared libgcc and glibc

["H . J . Lu" <hjl at lucon dot org>]

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.

> 
> 2. This means that one has to rebuild glibc whenever stuff is added to
>    libgcc.

1. It is not entire necessary. I have a script to rebuild/install
libgcc_s.so.0 from an installed gcc. But I don't want to make it
available to everyone. It is way too easy to break your machine
when libgcc_s.so.0 is wrong.
2. We can provide a configure time option to gcc to build/install
/lib/libgcc_s.so.0, not /usr/lib/libgcc_s.so. But I still think it is
too risky.
3. Since libgcc_s.so.0 is a system library, it should come from the
system vendor just like glibc. Build/install gcc shouldn't install
libgcc_s.so.0 by default. You can build/install libgcc_s.so.0 yourself
like glibc. But you have to know what you are doing.
4. You can always configure gcc with --enable-shared=libgcc and pray
your whole machine will be ok.

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

I am not sure if it is how the auxiliary filter works. From "info ld":

`-f'
`--auxiliary NAME'
     When creating an ELF shared object, set the internal DT_AUXILIARY
     field to the specified name.  This tells the dynamic linker that
     the symbol table of the shared object should be used as an
     auxiliary filter on the symbol table of the shared object NAME.

     If you later link a program against this filter object, then, when
     you run the program, the dynamic linker will see the DT_AUXILIARY
     field.  If the dynamic linker resolves any symbols from the filter
     object, it will first check whether there is a definition in the
     shared object NAME.  If there is one, it will be used instead of
     the definition in the filter object.  The shared object NAME need
     not exist.  Thus the shared object NAME may be used to provide an
     auxiliary filter on the symbol table of the shared object NAME.

     If you later link a program against this filter object, then, when
     you run the program, the dynamic linker will see the DT_AUXILIARY
     field.  If the dynamic linker resolves any symbols from the filter
     object, it will first check whether there is a definition in the
     shared object NAME.  If there is one, it will be used instead of
     the definition in the filter object.  The shared object NAME need
     not exist.  Thus the shared object NAME may be used to provide an
     alternative implementation of certain functions, perhaps for
     debugging or for machine specific performance.

Making libgcc_s.so.0 an auxiliary filter for libc.so will make sure
the defintions in libgcc_s.so.0 will be used instead of those in
libc.so. It will work even if libgcc_s.so.0 doesn't exist. It also
doesn't matter if your binary is linked against libgcc_s.so.0 or not.
I don't see how making libc.so an auxiliary filter for libgcc_s.so.0
will work/do anything more and why my approach won't.

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

What did you mean by that? You don't see the shared libgcc is a problem
for glibc, do you?


H.J.