This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Problematic linking between glibc and shared libgcc
- To: David Edelsohn <dje at watson dot ibm dot com>
- Subject: Re: Problematic linking between glibc and shared libgcc
- From: Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>
- Date: Wed, 21 Feb 2001 17:07:41 +0100
- Cc: Alexandre Oliva <aoliva at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, rra at stanford dot edu, gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com
dje@watson.ibm.com said:
> >>>>> Alexandre Oliva writes:
> Alexandre> This is not true. If you do move stuff, you may have to
> set Alexandre> LD_LIBRARY_PATH so that the moved libraries are still
> found, but Alexandre> that's all. I.e., it's no worse than having to
> set LD_LIBRARY_PATH Alexandre> always, and, in the general case, it's
> better, because you don't have Alexandre> to set LD_LIBRARY_PATH at
> all.
> I disagree with this slightly. There is the obscure case where the
> -rpath value points to a filesystem which no longer exists or has
> mounting problems. In that example, the invalid -rpath value can
> cause severe performance problems and essentially hang all
> applications depending on the shared library until a timeout occurs.
Well, that certainly can happen... I wonder how often though.
The key point here, I believe, is that there are very different
working models (depending on the organisation of the site, the OSes, ...).
For me, I have seen great benefits when LD_LIBRARY_PATH has been
declared evil. But I work on a site with 400-500 computers, and where
a lot has been made to provide redundant NFS servers and transparent
switching between those. Before that, figuring the proper LD_LIBRARY_PATH
was often a nightmare.
On the opposite side, there is of course my own PC on which I can do
whatever I want since I'm sole person working with it.
The length of this thread and the difficulty of finding a consensus
is a clear indication that some flexibility is needed here
...
That's why I proposed to have a configury option that leaves to the gcc
installer the decision of what magic word it wants to be inserted in the link
line for everyone on the site, the default being eg the current
setting where each gcc user. Only Brad showed enthousiasm and
Alexandre pointed out that there is not a single syntax that works.
In my mind, I was just allowing the installer to insert the string he
wants to in the spec file at the proper place but let him the
responsibility of the exact string to put. This allow all kind of
things, such as compiling and testing at one place and installing at
another one, etc...
[ Caution: Zack's proposal was much more elaborated
than what I write below, I just took the general idea out of it, do
not rely on my limited description of it to critize it. ]
Now, I must say that I found Zack's proposal much more interesting.
I surely do not know enough to be sure, but the crt.o seems a proper
place to put and initialize a global variable that is defined only
once for each program. No one has commented it yet, but it strikes me as the
best technical solution. If this cannot work, I would be interested
in having the explanation. If such a thing could work, we could even keep
a static libgcc with all the the exception code as it used to be
Of course, that means changing the crt.o for every port and I
understand that doing this is not that desirable just before 3.0.
On the other hand, I believe the problem is important enough to
take time to find the best answer NOW.
--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
--------------------------------------------------------------------
PGP signature