Subject: Re: static vs. dynamic runtime linking, again (was: PAM and su -K)
To: Ian Lance Taylor <ian@airs.com>
From: James Chacon <jmc@NetBSD.org>
List: tech-userlevel
Date: 01/25/2005 13:52:48
On Tue, Jan 25, 2005 at 02:34:38PM -0500, Ian Lance Taylor wrote:
> 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.

Yes. However gcc compeltely fails here. I as the user didn't add -L....
(some gnu specific path to libgcc_s) nor did I add a -lgcc. It's done
by the compiler and completely hidden from me. Which makes it completely
broken to the average user because it's *not* documented clearly at all...

At that point if you're gonna sneak compiler specific *dynamic* libraries 
into the dependency list for every executable you're building it's the
compilers duty to inform you about this somehow, or fix the situation so
the runtime can also find the library. Lets face facts here..gcc is a 3rd
party compiler so the excuse "libgcc_s should just be in a place all binaries
can find" is a cop out for not doing it cleanly/correctly.

James