> On Tue, 21 Jul 1998, Ross Harvey wrote:
> 
> : Interesting points. This subject comes up periodically when people haven't
> : set the -rpath _at all_, and then want the ld.so.conf and they advance the
> : obvious it-should-be-configurable argument.

Personally I think the -rpath mechanism is much much better than
the ldconfig one, because you can then have different applications
using different libraries at the same time, which just isn't feasible
with the ldconfig mechanism.

We compile all our applications with --prefix=/store so all the
interesting shared libraries (like libX11.so.6) is in /store/lib,
and we "always" have to specify -rpath.  Yes, sometimes it's a bit
of a pain, but it's worth the trouble, IMNSHO.

> : One big problem with the ld.so.conf approach is that it doesn't mix at all
> : well with -rpath, so by using ld.so.conf, you have to give up -rpath.

If we use ELF, we should *definitely* use the ELF mechanisms.
Mixing is just plain bad.

> Since when?  Isn't LD_LIBRARY_PATH a fallback in case the rpath doesn't
> match a real file?  Can't ld.so.conf do the same thing - act as a "system
> wide" LD_LIBRARY_PATH variable?  (If LD_LIBRARY_PATH is ignored when a
> -rpath is set, that's Broken.  It should be a _fallback_.)

No, LD_LIBRARY_PATH search happens *before* anything else, so you
should never set it as a permanent variable.  It should be used
only in wrapper scripts.

I could live with some way to configure the fallback path
(which in the ELF world is usually just "/usr/lib") that's used
*after* the -rpath search, to include more directories, say
/usr/lib:/usr/local/compat/lib where you could put various
libraries (or symlinks) so as not to pollute /usr/lib.

This could be used for applications you didn't compile yourself
and where -rpath is differently specified (or just wasn't used).
If you compile it yourself, please recompile with correct -rpath...

  -  Arne H. J.