This is the mail archive of the
mailing list for the glibc project.
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" <firstname.lastname@example.org>
> On Fri, Mar 23, 2001 at 12:37:36PM +0100, Mark Kettenis wrote:
> > "H . J . Lu" <email@example.com> 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
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
# 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.