Re: Problematic linking between glibc and shared libgcc

[Alexandre Oliva <aoliva at redhat dot com>]

On Feb 21, 2001, David Edelsohn <dje@watson.ibm.com> wrote:

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

I've discussed this case in the last paragraph of my message.  I don't
think having GCC installed in non-standard locations generate broken
executables/shared-libraries is a reasonable trade-off.  I'd advise
anyone facing such a timeout problem to rebuild the application such
that it no longer searches the broken directory, or to at least
arrange for the machine to no longer attempt to mount that directory,
at least temporarily.  It can't be that hard, and I don't think we
should force anyone using GCC with a prefix other than /usr to set
LD_LIBRARY_PATH because of this dubious scenario.

As a data point, libtool has always hard-coded library installation
directories in executables, and the only time this was disputed was
because of a misunderstanding about the consequences.  Someone thought
s/he'd be unable to move executables and libraries because of such
hard-coding.  Since this can be done, given the reasonable conditions
I posted in my previous message, I think it wouldn't be a problem if
GCC did it too.

The problem, as I explained in some other message, is that doing this
without modifying existing behavior is very tough.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me