James Chacon <jmc@NetBSD.org> writes:

> >      BTW, if you really want to talk about brokenness consider GCC
> > silently linking in extra libraries (i.e. libgcc_s.so) and not issuing
> > the appropriate rpath option.  Now that's broken!
> > 
> 
> This is why on solaris I patch gcc to at least push -R lines to the linker
> for this as well. Now, why the GCC maintainers insist the broken behavior
> is "correct" is beyond me...

Because it is correct.

The SunOS linker, which is what the SVR4 ELF linker is based on, had
no -R option.  Every -L option effectively became a -R option--that
is, every -L option was added to the runtime search path.  That meant
that when you did
    cc -o foo -L mydir1 -L mydir2 -llib1 -llib2
you got mydir1 and mydir2 in the runtime search path.  So when the
dynamic linker went to find your libc.so, it went grovelling through
mydir1 and mydir2.  Now suppose that mydir1 and mydir2 are NFS
mounted.  Now suppose that the NFS server machine happens to be
down--not a big deal, because it just has your build directories.
Except that now your binary hangs when you try to run it.

This used to happen to me regularly.  What an incredible pain it was.
Thank goodness ELF linkers separate the concepts of a link time search
path and a run time search path.

Of course separating the search paths introduces different problems.
There are various ways to finesse these.  The easiest way is to
clearly indicate which directories are system directories and hence
may be reliably searched.  This leads you to /etc/ld.so.conf.

Ian