How does Linux manage shared libraries (*.so) when it runs? Under Linux, the search and load of shared libraries is implemented by/lib/ld.so. Ld.so is looking for shared libraries used by applications in the standard path (/lib,/usr/lib).
However, if you need to use a shared library on a nonstandard path, how can ld.so find it?
Currently, it is common practice for Linux to add non-standard paths to/etc/ld.so.conf and then run Ldconfig to generate/etc/ld.so.cache. Ld.so when the shared library is loaded, it is looked up from Ld.so.cache.
Traditionally, Linux's predecessor, Unix, also had an environment variable: Ld_library_path to handle the shared library of nonstandard passes. ld.so when loading a shared library, it also looks for the path set by this variable.
Ld_library_path= $LD _library_path:./lib
Export Ld_library_path
However, there are many voices that claim to avoid using Ld_library_path variables, especially as global variables. These sounds are:
* Ld_library_path is not the answer-http://prefetch.net/articles/linkers.badldlibrary.html
* Why Ld_library_path is bad-http://xahlee.org/unixresource_dir/_/ldpath.html
* Ld_library_path-just say no-http://blogs.sun.com/rie/date/20040710
Another way to solve this problem is to specify Run-time path at compile time by using the-r<path> option.
1. To/lib and/usr/lib inside add things, is not modified/etc/ld.so.conf, but after the end to adjust ldconfig, otherwise the library will not find
2. If you want to add things to the above two directories, be sure to modify the/etc/ld.so.conf, and then call Ldconfig, otherwise you will not find.
For example, install a MySQL to/usr/local/mysql,mysql there are a lot of libraries under the/usr/local/mysql/lib, then you need to add a line under/etc/ld.so.conf/usr/local/ Mysql/lib, after saving Ldconfig, the new library can be found when the program is running.
3. If you want to put Lib outside of these two directories, but do not want to add things in the/etc/ld.so.conf (or do not have permission to add things). That can also be, export a global variable ld_library_path, and then run the program will go to this directory to find the LIBRARY. In general, this is a temporary solution that is used when there is no authority or temporary need.
4. These things that ldconfig do are related to running the program, and have nothing to do with the compile time. Compile the time or the addition-l will have to add, do not confuse.
5. In short, it is no matter what you do about the library changes, it is best to ldconfig a bit, otherwise there will be some unexpected results. It won't take much time, but it will save a lot of things.
Ld_library_path This environment variable is the most familiar to everyone, it tells loader: in which directories can find the shared library. You can set up multiple search directories separated by colons. Under Linux, there is another way to do the same, you can add these directories to/etc/ld.so.conf, and then call Ldconfig. Of course, this is a system-wide, globally valid, environment variable that is valid only for the current shell. By convention, unless you specify in the above-mentioned way, loader will not find a shared library in the current directory, just as the shell does not currently look for an executable file.
Linux Management shared libraries