"Greg A. Woods" <woods@weird.com> writes:

> > This turns out not to be the case.  The SVR4 linker does not default
> > the runtime search path to the -L arguments.
> 
> I didn't just rely on my possibly foggy memories of porting vast amounts
> of software to SysVr4 over a period of about three years in the early
> 1990's to make those claims -- I re-checked the old manuals I happen to
> have right handy here too and I'm pretty darn sure they fully
> corroborate my memories, and they seem to do so, although that old
> documentation is pretty sparse in places, esp. compared to modern
> SunOS-5 manuals, and there never was a proper manual page in the AT&T
> releases for the runtime dynamic linker.
> 
> First off note that the original SysVr4 link editor, as released by AT&T
> and USL up to and including the last 4.2 releases, did not even have a
> "-R" option to allow it to do otherwise (at least not for the i386
> port), (though it appears now in UnixWare-7, as I see from SCO's online
> manuals)....  It did have LD_RUN_PATH though to record a specific search
> path in the output object.

I admit that my experience was with Unixware and another SVR4 port
which I no longer recall, in the early 90s, as well as Solaris (or
SunOS-5 if you prefer).  I didn't use pure SVR4.  That was when I was
working on the ELF port of the GNU linker, so I examined the linker
behaviour very closely on all these systems.

> Presumably LD_RUN_PATH overrode the stored path generated from the '-L'
> options, though I always avoided the LD_* environment variables like a
> plague, especially since some software build systems I worked with had a
> tendency to occasionally use "make -e" when building.

Usually LD_RUN_PATH is used first, then any DT_RPATH recorded in the
executable, then the default (usually /usr/lib:/lib).  Of course
LD_RUN_PATH is ignored for a setuid executable.

> I thought this was NetBSD where one main goal "is emphasizing correct
> design and well written code".  Separating '-L' and '-R' without
> providing a decent default value for the new '-R' option when it's not
> explicitly specified, and thus offering proper backwards compatability
> for existing software build systems, is simply _not_ correct design.

Yes, I think /etc/ld.so.cache is a reasonable solution.  Defaulting -R
to -L is not, for reasons I already discussed.

(And I do agree as others have pointed out that gcc should do
something better for cases where it uses a shared libgcc.  Note that
gcc will not use a shared libgcc by default when using a sufficiently
new binutils, but g++ does.)

> There's no valid reason been given not to default the search path to one
> made up of '-L' parameters when no '-rpath' is given and every reason to
> do so, especially since all new and updated software will likely build
> with '-rpath' (or '-R') anyway, especially if it builds its own shared
> libraries too.

I gave a reason earlier in this thread.  Defaulting -R to -L can be a
serious problem in an environment which uses NFS heavily.  This was a
real problem for me on SunOS4 (which did not have -R at all).

Ian