This is the mail archive of the libc-alpha@sources.redhat.com 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 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%
>       ok?
> 
> 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
them? Should

# ./configure
# 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
implement it.

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


H.J.


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