[ On Friday, January 28, 2005 at 23:42:13 (+0200), Arto Huusko wrote: ]
> Subject: Re: static vs. dynamic runtime linking, and silly 'ld -L' breakage
>
> > > Yes, I think /etc/ld.so.cache is a reasonable solution.  Defaulting
> 
> By the way, I have never understood why NetBSD (web) documentation
> is so adamant that /etc/ld.so.conf is a really, really bad idea.

"nobody other ELF-based system has /etc/ld.co.conf, so NetBSD must not
either"  :-)

A run-time configuration of the default library search path is indeed
one reasonable solution to part of the problem.

But in my considered opinion it's not really an alternative to forcing
all developers to use '-R', even if all they end up doing is repeating
the '-L' options with the exact same, hard-coded, system directories.


> In a way, the point 4 in the ld.so.conf entry of the web page
> above is kind of ironic in this light: "the system should just
> work..."

The problem is that there is no way to force developers to only
link-edit their programs _after_ they have installed any and all shared
libraries that they will also use.  A program simply cannot intuit that
a library is in its final resting place, even if the pathname used to
find it is absolute.

Unfortunately the SunOS folks took an equally drastic, but opposite,
approach and they require that all developers do one of two or three
possible things at link-edit time to always record the expected runtime
location and/or search path for all dynamic objects, while still also
providing the location of the library at link-edit time.

We need a happier medium.

/etc/ld.so.conf is indeed one approach, but it seems to fly in the face
of what some folks perceive as a Golden Rule of some sort for all ELF
platforms.

Defaulting the runtime search path to be a path made up of the '-L'
directories (along with the system default paths) even when those might
be relative directory references, is another valid approach, and one
that was used for a very long time (decades?) on some systems, including
early NetBSD (pre-ELF).  However some folks seem so terrified that
they'll allow a developer to create a binary that won't run, that they
absolutely detest this time-honoured and well proven technique.

We could also add /usr/X11R6/lib:/usr/pkg/lib:/usr/local/lib to the
default system search path.

We could even have all three, but that does increase complexity.


What we _REALLY_ need most urgently is better documetation in NetBSD.
SunOS and IRIX have lots of good ideas in their docs we might borrow
from just so long as we're careful to re-write it adequately to avoid
copyright issues.  Anyone who's going to work on the docs should first
read all these similar documents, along with John Levine's "Linkers and
Loaders" book, then go away on vacation for a couple of weeks (or at
least do something completely unrelated for a while), and then update
the NetBSD docs with only the GNU originals and the working toolchain
itself (along with its sources) as direct references.

We could also use is a heck of a lot better support in the tools to help
system managers and developers alike understand what's going on when
something fails.  For example ldd(1) really should spit out the search
paths it will use (and thus those which ld.elf_so would also use with
the same environment), and also tell us whether it used the search path
(and maybe which search path, DT_RPATH, default path, LD_LIBRARY_PATH,
LD_PRELOAD, etc.)  or a DT_SONAME, to find each dynamic object.  Right
now all this information is spread around over hell's half acre and you
need three or four tools, some of which are extremely complex to use, to
really figure out all the where's and why's.


Here we begin to see at least the tip of the iceberg that embodies all
the various issues surrounding dynamic-loaded shared libraries.


-- 
						Greg A. Woods

H:+1 416 218-0098  W:+1 416 489-5852 x122  VE3TCP  RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>          Secrets of the Weird <woods@weird.com>