1. basic concepts of static and dynamic libraries
the static library is added to the Execution Code when the Program connection is executable, physically, it becomes a part of the execution program. When you use a static library to compile a program, you do not need to support the library file. It can be used wherever possible, but the generated executable file is large. The dynamic library is loaded into the execution program when the executable program starts and can be shared by multiple executable programs. The programs generated by using dynamic library compilation are relatively small, but library files are required for running. If these library files are not available on the machine, they cannot be run.
2. How to use dynamic libraries
when a program uses a shared library during connection, the location of the shared library must be found during running. By default, the executable programs in Linux search for the/lib and/usr/lib directories first, and then follow/etc/lD. so. the absolute path of the configuration search in Conf. In addition, Linux provides the environment variable LD_LIBRARY_PATH for users to choose from. You can set it to find other paths except the default path, such as/work/lib path, you can go to/etc/rc. d/RC. add the following statement to the script that can be executed after local or other systems are started: LD_LIBRARY_PATH =/work/lib: $ (LD_LIBRARY_PATH ). In addition, the LD_LIBRARY_PATH path takes precedence over the system default path (for details, see "use LD_LIBRARY_PATH").
however, LD_LIBRARY_PATH is set globally. Excessive use may affect the running of other applications, so it is mostly used for debugging. (For LD_LIBRARY_PATH defects and usage principles, see why LD_LIBRARY_PATH is bad.) We recommend that you use the-R or-rpath option of GCC to specify the library search path during compilation, and save the library path information in the executable file, when running, it will directly go to the path to find the library, avoiding the use of LD_LIBRARY_PATH environment variable search.
3.Library connection path and runtime path
the modern connector separates the link-time path and the run-time path when processing a dynamic library, you can use-L to specify the path of the database to be connected and you can use-R (or-rpath) to specify the path of the library to run the program , which greatly improves the flexibility of the library application. For example, when we perform embedded transplantation # arm-Linux-GCC $ (cflags) -O target-L/work/lib/zlib/-llibz-1.2.3 (work/lib/zlib is a cross-compiled zlib library ), after compiling target, we only need to copy the zlib library to the default system path of the Development Board. You can also use-rpath (or-R) and LD_LIBRARY_PATH to specify the search path.
Minor issues:
1.Does the-L option during compilation affect the value of LD_LIBRARY_PATH?
For example:
The current folder structure is as follows:
Test. c tools/
Tool. c tool. h my_err.h and the generated libtool. So
Compile and generate library files under Tool
Gcc-wall-g-shared-O tool. So tool. c
Reference in the current folder:
Gcc-wall-g-o test. C-ltools-ltool
No error is reported during compilation, but the cannot open shared object file is displayed during running and loading.
If you copy the library file to/usr/lib, there is no error and the database runs normally.
note that the-L option during compilation does not affect the environment variable LD_LIBRARY_PATH , -l only specifies the path of the library during program compilation and connection, and does not affect the path of the library during program execution. The system still searches for the library required by the program in the default path.
Original: http://www.xxlinux.com/linux/article/development/soft/20070925/9913.html