On Thu, 11 Mar 1999 21:44:02 -0500 (EST) 
 Todd Vierling <tv@pobox.com> wrote:

 > Jason, we've been through this hoop a dozen times.  WHAT BREAKS on a
 > properly configured, rpath-only system if we allow people to use the
 > `historic' library search method for their own uses?
 > 
 > Think (open("/etc/ld.so.conf", ...) == -1).
 > 
 > It's not like we're doing things such as minor version handling....

I honestly don't care if it "works" if I simply don't install an
ld.so.conf.  But I don't even think it's appropriate to supply
the rope, here.

Let's take it from the top:

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!

This is an actual real, plausible scenario which breaks with ld.so.conf.

If you move a shared library, and want your programs to continue working,
USE A BLOODY SYMLINK.  But don't break an otherwise working system just
to make your life easier.

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>