Matthew Saltzman wrote:
On Wed, 2007-06-06 at 09:55 -0600, Phil Meyer wrote:
I am no expert in compilers, but this issue has existed sin we were
doing gcc on Solaris 2.1 (1992). Someone with better knowledge feel
free to respond, but these are my observations:
root has special precautions about prepended library paths. That is a
common trick of old security hackers.
In modern times. LD_LIBRARY_PATH simply should not be used any where.
When building an application you can set LD_RUN_PATH and that will embed
the run path into the binary.
For applications that might move locations, there has been a method
provided for years, by placing a simple text file with a run path in
/etc/ld.so.conf.d the loader linker will use it as if LD_LIBRARY_PATH
had been set.
This makes for an easily relocatable rpm, because the rpm can drop a
text file in there that points to wherever the rpm has been located.
In your example above, simply change LD_LIBRARY_PATH to LD_RUN_PATH and
you will get what you want, AND users will not need to set LD_LIBRARY_PATH.
Some discussion here:
http://osr507doc.sco.com/en/tools/ccs_linkedit_dynamic_dirsearch.html
LD_RUN_PATH seems to be absent here:
http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Environment-Variables.html#Environment-Variables
So maybe I am just getting old, but I am sure that the principle is
good, even if my failing memory is not. :)
I still don't have a good answer to the following question:
I'm a normal user (not root) and I'm creating software for my own use.
I don't have access to /etc/ld.so.conf.d (and even if I did, I don't
want to publicize my personal lib directory). I want to build a
dynamically linked binary linking to a dynamic library of my own (not in
the usual system paths). I'd also like to be able to send my friends my
library and binary and not make them recompile it.
If I'm not supposed to use LD_LIBRARY_PATH to let the binary know where
to find my personal libs, what's the best other way to do it?
You can embed the library path into the resulting binary. That way the
linker will search that path each time the binary is executed.
This is done (used to be done? ) by setting LD_RUN_PATH before doing the
compile.
This environment variable may have changed names with newer versions of
gcc. According to the gnu doc that I listed, the new fangled way is
with LIBRARY_PATH. Note the absence of LD,
So it would go like this:
$ LIBRARY_PATH=/home/myhome/libs
$ export LIBRARY_PATH
$ gcc -o myprog myproc.c -lmylib
Now anyone can run myprog and the loader linker will look in
/home/myhome/libs every time it is executed.
No need for LD_LIBRARY_PATH, and no need for LIBRARY_PATH after the build.
Hope this helps, and I hope this is accurate. It used to be using
LD_RUN_PATH, maybe it still is, I have not tested the 'new' way.
