Why is LD_LIBRARY_PATH unset in FC6 and not in FC5
pmeyer at themeyerfarm.com
Wed Jun 6 17:37:33 UTC 2007
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:
>> LD_RUN_PATH seems to be absent here:
>> 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
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:
$ 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.
More information about the users