Re: LD_LIBRARY_PATH

[Russ Allbery <rra at stanford dot edu>]

Gerald Pfeifer <pfeifer@dbai.tuwien.ac.at> writes:

> This is an issue coming up again and again, and it really seems to
> burn users, especially since we switched to libgcc_s.so.

> http://gcc.gnu.org/java/build-snapshot.html already has a bit on
> LD_LIBRARY_PATH, though I believe we also need something in our main
> installation documentation.

> The questions is: What exactly do we want to document, and how?  Do
> we just want to state

>   After the installation, you will probably need to add $prefix/lib
>   to LD_LIBRARY_PATH, so that dynamic executable can locate their
>   libraries

> or something more elaborate?

I think setting LD_LIBRARY_PATH is dangerous to recommend to users who may
not know better or understand the implications, since it's a global change
that affects every binary they run.  If they have some other libraries in
that directory, they suddenly override libraries that might have
previously been found elsewhere.  I'm pretty sure Stanford isn't the only
site that has a policy of never setting LD_LIBRARY_PATH and recommending
our users don't set it except as is necessary for running particular
vendor packages (and then, using wrapper scripts to do it).

Using -R or the equivalent, or setting LD_RUN_PATH or the equivalent, is
considerably safer since it only affects that particular binary and not
system binaries, vendor software, and anything else a user may run.

(It may be worth noting that this particular headache is the primary
reason why we've yet to upgrade past GCC 2.95.3 for our site-wide
installation.)

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>