This is the mail archive of the 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

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

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/
 > GROUP (
 > /lib/
 > -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/,
with all the problems about re-exportation and uniqueness of EH

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 without having to rebuild it?

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

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/, not /usr/lib/ But I still think it is
   >    too risky.
   > That would indeed be tricky.
   >    3. Since is a system library, it should come from the
   >    system vendor just like glibc. Build/install gcc shouldn't install
   > by default. You can build/install 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/ or put 2 on
   system unless "--enable-shared=libgcc" is passed to "configure". But
   gcc should use /usr/lib/ if it exists and is compatible.

Unconditionally overwriting /lib/ 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 and

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

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, -Wl,-soname, ......

   to build, you tell to use the definitions in to override those in if exists.
   You can forget those definitions even exist as long as
   sees 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. will have a DT_AUXILIARY entry set to, such
that the stuff from overrides things in

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


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