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 02:34:13PM +0100, Mark Kettenis wrote:
Ok. We should just do
# ln -s ../../lib/libgcc_s.so.0 /usr/lib/libgcc_s.so
> 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 have proprosed --enable-shared=libgcc just to do that. I'd like
to have a way to check if the installed libgcc_s.so is ok during
the gcc configure. We can add a new variable, __libgcc_abi_version,
to libgcc.so. We bump it up everytime an ABI change is made.
> 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.
Well, if the affected programs are crucial to your machine or
application, you are screwed. I never said gcc shouldn't install
its own libgcc.so. It just shouldn't do that by default. I want to
avoid it as much as I can.
One more example, you have a system daemon like process, foo, which can
dlopen a user application, bar. If you have 2 libgcc.so, one in /lib
and another in /usr/local/lib, which one should foo use and which one
should bar use? If the one in /usr/local/lib is newer than /lib and
bar needs the one in /usr/local/lib, you have to make sure foo uses
the one in /usr/local/lib for bar to be dlopened from foo. Having
2 incompatible libgcc.so is not something I want to see. On the
other hand, it doesn't make any senses to have 2 identical libgcc.so
on a machine.
> 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.
I won't count on that. I prefer the one from the system vendor. Also
what about the snapshots or prereleases? Should Linux people test
# make bootstrap
# make install
in a snapshot/prerelease gcc install libgcc.so by default?
> 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.
I only run glibc. I know glibc/binutils well enough to figure out
a way to fix it. Why should I care if my approach doesn't work on
xxxxx? Besides, I don't see the gcc people believe it is a serious
problem for glibc or anyone else for that matter.
> # 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 guess we misunderstood each other. I have a small glibc patch to
> > 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.
Some people don't want to hear solutions which only work on glibc.