Subject: Re: patch to allow /etc/ld.so.conf configure directories for ELF
To: Todd Vierling <firstname.lastname@example.org>
From: Jason Thorpe <email@example.com>
Date: 03/11/1999 18:55:49
On Thu, 11 Mar 1999 21:44:02 -0500 (EST)
Todd Vierling <firstname.lastname@example.org> 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:
(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
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 <email@example.com>