Setting LD_LIBRARY_PATH environment variable for loading a shared library at runtime (g++)

Question

I'm having two problems related to the same issue:

1. I have a shared object saved in `pwd`/lib and while the executable that uses it compiles successfully (by using -l and -L switches), at runtime, it's giving me grief. If I try to run LD_LIBRARY_PATH=/my/absolute/path/to/library/directory ./test it works fine. But if I export LD_LIBRARY_PATH=/my/absolute/path/to/library/directory and do ./test it says that it can't find the shared library. However, if I do LD_LIBRARY_PATH=$LD_LIBRARY_PATH ./test again it works fine!! Any ideas on what I'm doing wrong?

2. Second issue is related to the exporting of the LD_LIBRARY_PATH env variable. If I open a terminal and type export LD_LIBRARY_PATH=/path/to/stuff and then type echo $LD_LIBRARY_PATH, the variable is correct. However if I write a script containing the export command, simply running it doesn't update the variable, instead I need to run source install.sh in order to actually persist the variable. What's the best solution for this?

Thank you for your time!

Wilton

Answer 1

To answer the second question first:

source executes the script inside the current shell, ./install.sh opens and executes it in a different shell. http://www.unix.com/unix-dummies-questions-answers/537-difference-between-source-exec-script.html

Now for your first question:

LD_LIBRARY_PATH=$LD_LIBRARY_PATH ./test sets the LD_LIBRARY_PATH variable before just one command (the ./test command). For the same reason above, I believe this isn't getting transferred to whatever shell ./test creates. To make it persist, you may need to put the export LD_LIBRARY_PATH=... in your ~/.bashrc

Australorp

Thanks for the answer! I'm trying to find a way to setup the path to the shared objects without using sudo commands (and put it in /usr/local/lib) or changing user's bash file. Is there a generally accepted way of doing it? – Wilton

Hmm, I think there's no "safe" way to do it, but look here: (linuxquestions.org/questions/linux-software-2/…). I don't know too much about this but I've seen recommendations to wrap your main program in a simple script that sets the library path, runs your actual program and then unsets it. Instead of calling your program directly, users should run the script. – Australorp

Actually, this may help: osr507doc.sco.com/en/tools/ccs_linkedit_dynamic_dirsearch.html It is about the LD_RUN_PATH variable, which allows you to specify your library locations at link-time (an alternative to LD_LIBRARY_PATH, which "lets you do the same thing at run time"). This is about the limit of my knowledge on this, sorry ... – Australorp

Thanks, I'll go with the script then. The LD_RUN_PATH is for compile time afaik, and that's already taken care of with -L. – Wilton

Answer 2

I have found sometimes adding -L explicitly via the CFLAGS environment variable is successful when LD_RUN_PATH was not. As in: export CFLAGS=-L/opt/tool/lib

Furnace