Re: Try to solve shared libgcc and glibc

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

On Sat, Mar 24, 2001 at 01:18:23AM +0100, Mark Kettenis wrote:
>    Date: Fri, 23 Mar 2001 08:51:43 -0800
>    From: "H . J . Lu" <hjl@lucon.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.
> 
> I'm basically talking about the current situation where shared
> libraries that reference any symbols in libgcc.a will reexport those
> symbols.  If you don't think that this is a problem ask yourself why

They won't if they are linked against -lgcc_s.

> we have __divdi3, __moddi3, __udivdi3 and __umoddi3 in
> sysdeps/i386/Versions.

We can turn them off without much problem if we want. I even proposed
a patch for egcs 1.1.x to do just that.

> 
>    > 
>    > 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.
> 
> I cannot follow you here.  How does one update stuff originating from
> libgcc that lives in libc.so without having to rebuild it?

With libgcc_s.so.0 as the auxiliary filter for libc.so, those libgcc
symbols in libc.so will never be used if libgcc_s.so.0 exists. That is
how the auxiliary filter works. We just need to update libgcc_s.so.0.

> 
>    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.
> 
> That would indeed be tricky.
> 
>    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.
> 
> Linux vendors will have to privide a libgcc_s package and use their
> dependency tracking system to make sure their users have an up to date
> version of libgcc installed.
> 
> People installing GCC from sources will have to copy the shared libgcc
> into /lib (or /usr/lib) manually if they use it to compile any stuff
> in / (or /usr).  I fail to understand why this means that GCC
> shouldn't install the shared libgcc by default.

By that, I meent

# ../configure
# make bootstrap
# make install

should never overwrite /lib/libgcc_s.so.0 or put 2 libgcc_s.so.0 on
system unless "--enable-shared=libgcc" is passed to "configure". But
gcc should use /usr/lib/libgcc_s.so if it exists and is compatible.

> 
>    4. You can always configure gcc with --enable-shared=libgcc and pray
>    your whole machine will be ok.
> 
> As long as installing GCC doesn't overwrite a more recent version of
> the shared libgcc, I don't see how things could go wrong.

1. How do you know the shared libgcc in a particular gcc is 100% ok?
2. How do you know installing GCC won't overwrite a more recent version
of the shared libgcc?

> 
>    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.
> 
> I don't understand "your approach", since you didn't explain how it is
> supposed to work, and I am too stupid to figure it out from the code
> you provided.  I do understand Richard's approach though since he did
> provide an explanation.
> 
> You know what?  If you care to explain your approach, I'll try to
> explain Richard's.

I have quoted the info page in ld and I even provided a small testcase.
When you use

# gcc -Wl,-f,libgcc_s.so.0 -Wl,-soname,libc.so.6 ......

to build libc.so.6, you tell ld.so to use the definitions in
libgcc_s.so.0 to override those in libc.so.6 if libgcc_s.so.0 exists.
You can forget those definitions libc.so.6 even exist as long as ld.so
sees libgcc_s.so.0 at the run-time.

> 
> I don't see why it is a problem specific to glibc.  I do think it's

I only use glibc. Why should I worry systems I have no access to? I
don't have a clue how to fix the problem on them.


H.J.