Re: Try to solve shared libgcc and glibc

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   Date: Fri, 23 Mar 2001 21:35:42 -0800
   From: "H . J . Lu" <hjl@lucon.org>

OK, I think I'm beginning to understand what you want to accomplish.

   On Sat, Mar 24, 2001 at 01:18:23AM +0100, Mark Kettenis wrote:

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

Sure, but you were suggesting to use the following linker script:

 > # cat << EOF > /usr/lib/libgcc_s.so
 > GROUP (
 > /lib/libgcc_s.so.0
 > -lgcc
 > )
 > EOF

which means that if symbols get added to libgcc in a future version of
GCC, they will be taken from libgcc.a instead of /lib/libgcc_s.so.0,
with all the problems about re-exportation and uniqueness of EH
functions.

The re-exportation problems can be solved by the .hidden/.protected
ELF stuff, but the EH stuff should never come from libgcc.a.

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

There is no reason to do that.  Having duplicate copies of these
functions is fine.

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

Sure.  You just didn't make clear that you were proposing to do that.

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

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

Unconditionally overwriting /lib/libgcc_s.so.0 when installing GCC
would indeed not be very wise, but I don't think you should not
prevent GCC from installing its own version of the shared libgcc,
especially if any interfaces were added in the meantime, otherwise
you'll miss those interfaces or get those from libgcc.a.

I fail to see why having two shared libgcc's on one system is a
serious problem.  I don't think the dynamic linker will ever load two
libraries with the same soname.  The worst that can happen is that a
program won't run because the shared libgcc that's being isn't recent
enough.  The dynamic linker should catch this and print an obvious
error message.

In the past when asked for proof of problems with two versions of the
same shared library you have given the example of having two different
versions of glibc installed.  This probably isn't a good example,
since AFAICT those problems are caused by the fact that we do not
properly version the interface between ld-linux.so.2 and libc.so.6.

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

You never know of course.  Official GCC releases should have had
enough testing to be reasonably certain that its libgcc is OK.

   2. How do you know installing GCC won't overwrite a more recent version
   of the shared libgcc?

For example by configuring with --enable-version-specific-runtime-libs.  
The point is that this isn't a Linux/glibc-specific issue, so this
shouldn't be addressed in a Linux/glibc-specific way.

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

Ah, that makes sense.  I couldn't infer this from your origional
message.  This is exactly how Richard Henderson envisioned it.
libc.so.6 will have a DT_AUXILIARY entry set to libgcc_s.so.0, such
that the stuff from libgcc_s.so.0 overrides things in libc.so.6.

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

Sharing knowledge and solutions can be pretty useful.

Mark