链接与运行时动态库依赖

The -L option supplies a colon-separated library path that is to besearched at LINK TIME for libraries. Thuscc -o foo foo.c -L/usr/local/lib -lfoomeans that either libfoo.a or libfoo.so should be found in either/usr/local/lib, or elsewhere in the default search patch (inGNU/Linux, the directories can be listed in /etc/ld.so.conf, and thecache updated by running /etc/ldconfig).Whether the .a or .so form of the library is needed is platformdependent (e.g., IBM AIX uses only the .a form), and also dependent oncompiler options to select dynamic or static linking.  The default isnormally dynamic linking to save disk space and waste CPU time.However, this means while that the executable foo may have beensuccessfully linked against a shared library, at RUN TIME, therun-time loader looks for it in the default search path, possiblyprefixed by a colon-separated list of libraries supplied by theLD_LIBRARY_PATH variable.If, in our example, /usr/local/lib is not part of the default path,then the run-time loader will not be able to find the shared library,EVEN THOUGH LINKING SUCCEEDED (because of the -L/usr/local/liboption).You can check whether shared libraries can be found by runningenv -i ldd foo(the "env -i" says to ignore any existing environment variables, suchas LD_LIBRARY_PATH).For example, on one of my systems, I find% env -i ldd /usr/local/bin/emacslibXaw3d.so.5 =>         (file not found)libXmu.so.4 =>   /usr/lib/libXmu.so.4libXt.so.4 =>    /usr/lib/libXt.so.4...Notice the "(file not found") line.  That library is actually presenton that system in /usr/local/lib, and I can make it succeed like this:% env -i LD_LIBRARY_PATH=/usr/local/lib ldd /usr/local/bin/emacs        libXaw3d.so.5 =>         /usr/local/lib/libXaw3d.so.5        libXmu.so.4 =>   /usr/lib/libXmu.so.4...Thus, when shared libraries are present in nondefault directories, youneed to supply an additional linker option, usually -R or -Wl,-rpath=,with a run-time library path.  Our example above becomes for gccgcc -o foo foo.c -L/usr/local/lib -lfoo -Wl,-rpath=/usr/local/libIn a Makefile, I would write this asgcc -o foo foo.c -L$(prefix)/lib -lfoo -Wl,-rpath=$(prefix)/libso that the same library path is used at link time as at run time, andso that the executable file, foo, records that path.  With GNUautoconf, the normal condition is that prefix is the root of the filetree into which you install software locally, so the above command isfairly typical.  Unfortunately, software developers who havenondefault library search paths often forget to supply the -Wl,-rpathor -R options in their Makefiles, with the result that the code buildsand runs at their sites, but not at end user sites.>From notes that I keep:>> ...>> Unfortunately, there are at least three incompatible kinds of>> command-line options that tell the compiler to instruct the linker to>> save library paths in the executable:>>>> -Wl,-rpath,/path/to/dirgcc, g++, FreeBSD, SGI, Sun compilers>> -rpath /path/to/dirCompaq/DEC, SGI compilers>> -Rdir:dir:dirPortland Group, Sun compilers>>>> Notice that SGI and Sun support two such flavors.>> ...In my view, there is clearly brain damage here: (1) compiler writersshould have standardized on the same option name for recording therun-time library path (I'd vote for -R), and (2) the linker shouldreally record the run-time library path by default, so that -R would
almost never be needed.
Address:
http://gcc.gnu.org/ml/gcc-help/2005-12/msg00017.html