Re: Problematic linking between glibc and shared libgcc

[Theodore Papadopoulo <Theodore dot Papadopoulo at sophia dot inria dot fr>]

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