On Thu, Mar 11, 1999 at 06:55:49PM -0800, Jason Thorpe wrote:
> Let's say you have a program called foozle.  There are several associated
> programs (foobazle, foowhatziz) that all share a common shared library
> called "libutil.so.4".  The package installs it as:
> 
> 	/usr/pkg/lib/foozle/libutil.so.4
> (along with whatever other shared libraries it uses).
> 
> Note that it does not link against the NetBSD system "libutil".
> 
> This is _perfectly legitimate_, because the portable foozle package
> also uses the RPATH facility on IRIX, Solaris, and BSD/OS to get the
> path right (on Solaris, maybe that's /opt/foozle/lib/libutil.so.4).
> 
> If you RPATH this, and allow ld.so.conf, which libutil.so.4 is ld.elf_so
> supposed to pick?  Even if you allow RPATH _with_ ld.so.conf, you are
> screwed here!

Hrm.. I don't care much about this subject, I'm used to ELF systems
that use either method. But this example does not make a good case
against the proposed use of ld.so.conf.

The search order for our ld.elf_so is:

	1) rpaths in the object(s)
	2) default path (defined to be /usr/lib:/usr/local/lib in the source)
	3) LD_LIBRARY_PATH

What Matt is proposing, is a possibility to add something between 2) and 3).
Now, if the foozle binaries are properly linked (which is a seperate issue;
let's assume that they are), using the /usr/pkg/lib/foozle runpath, this
will always be found first. So, you can put any directory in Matt's
version of ld.so.conf you want, it won't matter, ld.elf_so won't even get
to it for libutil. Having it is not going to make you lose here. The fact
that having multiple shared libraries with the same name will lead to
confusion and lossage if not properly managed has nothing to do with the
ability of adding a few directories to the default path through some
mechanism in this case.

Or am I missing something?

What I would agree on, however, is that adding some directories to
the default search path provides an opportunity for a system manager
to mismanage shared libraries in general, i.e. instead of linking properly
with an rpath, all directories just get crammed into the ld.so.conf 
file. Which will indeed lead to unexpected lossage. But is that a 
reason not to include it? I don't know. You can't really stop a sysadmin
who doesn't know what s/he's doing from doing harm. He/she could just
add symlinks in /usr/lib for every library, which is just as stupid and has
the same effect. Not calling the file with the extra pathnames "ld.so.conf"
would be a good idea, indicating that it's used for something else,
and avoiding a.out -> ELF transition lossage.

- Frank