On Sat, 19 May 2007, Tony Nelson wrote:
Well, everyone was helpful. Turned out that when I ran "echo
LD_LIBRARY_PATH" it was empty. I added /usr/local/lib by typing (I
think): ]$ LD_LIBRARY_PATH=/usr/local/lib and then:
export LD_LIBRARY_PATH
That should do it, at least until I have to shut down and boot up
again. :)
Tom
Google on "linux library search path" to find out why LD_LIBRARY_PATH isn't
such a good idea.
I'm afraid to look. :)
What's a better alternative?
AIUI, either putting the lib in a standard location (/usr/lib) or adding a
file to /etc/ld.so.conf.d/ and then running ldconfig (man ldconfig). The
suggestion was that LD_LIBRARY_PATH affects all uses of shared libs and
that can have unintended consequences. Perhaps /usr/local/lib is safe
enough.
A normal user can't install a shared-lib package for his own use in, say,
~/lib this way because (1) he needs root to update the ld.so database and
(2) even if he could update the ld.so database, it would then include a
path inaccessible to other users. Also, you don't want net-mounted
filesystems in the ld.so path because if they are unavailable, nothing can
load.
The other alternative is to build the paths to shared libs into the binary
itself at link time. The problem with that is that the libs then have to
be installed in the specified locations (again probably requiring root and
possibly violating installation standards) or the user has to build the
binary himself with the lib locations specified. The latter is the best
alternative, as long as the source is available and the user is
experienced enough to build it.
If a normal user gets a package prebuilt with shared libs, he's kind of
stuck. In this case, the best bet is probably a wrapper script that sets
LD_LIBRARY_PATH only for the environment in which the particular binary is
run.
See, e.g,, http://www.eyrie.org/~eagle/notes/rpath.html.
--
Matthew Saltzman
Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
