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 02:34:13PM +0100, Mark Kettenis wrote:

Ok. We should just do

# ln -s ../../lib/ /usr/lib/

>    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 have proprosed --enable-shared=libgcc just to do that. I'd like
to have a way to check if the installed is ok during
the gcc configure. We can add a new variable, __libgcc_abi_version,
to 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 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, 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 is not something I want to see. On the
other hand, it doesn't make any senses to have 2 identical
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 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, -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 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.


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