Joe Orton <joe@manyfish.co.uk> writes:
> So, you have installed OpenSSL's shared libraries into /usr/foo/lib.
> Instead of making a one-time modification to your runtime linker
> configuration (or adding a LD_LIBRARY_PATH/LD_RUN_PATH to your
> ~/.profile, etc etc), you want every application to add stuff to it's
> ./configure script, to make it work for you. Hmmmm. ;)
So you've installed OpenSSL's shared libraries into /usr/foo/lib, where
/usr/foo is an enterprise-wide file system mounted on a thousand different
Unix machines. Now, rather than having Subversion correctly link against
those libraries, you want a thousand system administrators to go make
custom changes to their runtime library configuration that may break other
applications.
I don't really care; I set LD_RUN_PATH for everything I build because so
many applications make the same choice that you're advocating. But I
think you're making the wrong choice. LD_LIBRARY_PATH is broken by design
and should never be used except with closed-source applications that you
can't relink since it can cause very difficult-to-understand random
breakage in existing applications whenever it changes and because it can
get clobbered by applications that have conflicting requirements.
ld.so.conf isn't much better, plus is a change that has to be made on the
local system and can't be handled by the application installer. Encoding
the correct path to the shared libraries is the correct solution, in my
opinion. If that path changes, a simple rebuild is easy, and that path
changes very rarely in my experience.
--
Russ Allbery (rra_at_stanford.edu) <http://www.eyrie.org/~eagle/>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:08 2006