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

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" <>
>    On Fri, Mar 23, 2001 at 12:37:36PM +0100, Mark Kettenis wrote:
>    > "H . J . Lu" <> 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 during the glibc build. We
>    > > provide as
>    > > 
>    > > # cat << EOF > /usr/lib/
>    > > GROUP (
>    > > /lib/
>    > > -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/ 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
> 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 is wrong.
> 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

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

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

>    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 an auxiliary filter for will make sure
>    the defintions in will be used instead of those in
> It will work even if doesn't exist. It also
>    doesn't matter if your binary is linked against or not.
>    I don't see how making an auxiliary filter for
>    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, -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.

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


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