Russ Allbery wrote:
> 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.
Personally, I find hunting down and recompiling every application that
links to a library far more confusing and painful.
> 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.
Obviously people have different opinions on this matter. :) I
personally don't think the path to a *dynamicaly* loaded library should
be staticaly written into the application. If you want that, just link
everything into the application. Then you never have to worry about
mysterious breakage. ;)
I'm not saying ld.so.conf is the ideal way of allowing this in a perfect
world, but I'd rather have that than nothing. Windows DLLs are searched
for in the program's directory, in the system directory (and in the
path??)... windows suffers somewhat from having way to many files spread
all over the damn place but at least the DLL paths aren't hard coded.
You can at least dump a different DLL into the application's directory
if you want it to use a different version.
Julian
--
julian@beta4.com
Beta4 Productions (http://www.beta4.com)
---------------------------------------------------------------------
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