问题
I wrote a shared object, say libsd.so, and I put libsd.so and its header file sd.h in ~/lib.
Here is another program using libsd.so, say test.c, then compile it like this:
$ gcc -o test test.c -I~/lib -L~/lib -lsd
Then I run test like this:
$ ./test
./test_sd: error while loading shared libraries: libsd.so: cannot open shared object file: No such file or directory
So I set export LD_LIBRARY_PATH=., then it works. But if I unset LD_LIBRARY_PATH and put LD_LIBRARY_PATH=~/lib in my ~/.bashrc, then source ~/.bashrc, again it doesn't work for ./test, WHY?
export LD_LIBRARY_PATH=~/lib is difference from putting LD_LIBRARY_PATH=~/lib in ~/.bashrc?
回答1:
Without the export your declared LD_LIBRARY_PATH is only valid in the script (.bashrc). With the export it should work, but it is usually not a good idea to set your LD_LIBRARY_PATH like this.
If you don't want to install your library in the system path (e.g. /usr/lib) you should probably use a script that sets LD_LIBARAY_PATH locally and starts your application.
回答2:
Try $HOME/lib instead of ~/lib - it should be the same but I've seen cases where ~ wasn't expanded properly when used in an variable assignment.
To check, try echo $LD_LIBRARY_PATH which gives you the current value.
Re export: If you omit the export, then the variable is only known to the current shell process and will not be exported to child processes. So if you omit it, echo $LD_LIBRARY_PATH will get the value because the variable is expanded by the shell before the echo command/builtin has a chance to do anything. But ./test won't see it because it's not exported to the new subprocess.
来源：https://stackoverflow.com/questions/9412296/ld-library-path-the-shared-lib-path-in-linux