There are two different types of Linux executable programs on Linux. The first type is static linked executable programs. Static executable programs include all the functions required for execution-in other words, they are "complete ". For this reason, static executable programs can run without relying on any external library. The second type is dynamic linked executable programs. Comparison between static and dynamic executable programs We can use the LDD command to determine whether a specific executable program is statically linked: # LDD/sbin/SLN Not a dynamic executable "Not a dynamic executable" is a method in which LDD indicates that SLN is a static link. Now, let's compare the size of the SLN and its non-static similar ln: # Ls-L/bin/ln/sbin/SLN -Rwxr-XR-x 1 Root 23000 Jan 14 00:36/bin/ln -Rwxr-XR-x 1 Root 381072 Jan 14 00:31/sbin/SLN As you can see, the SLN is more than 10 times the ln size. Ln is much smaller than SLN because it is a dynamic executable program. Dynamic executable programs are incomplete programs that rely on external shared libraries to provide the many functions required for running. Dynamic Link correlation To view the list of all the shared libraries on which ln depends, run the LDD command: # LDD/bin/ln Libc. so.6 =>/lib/libc. so.6 (0x40021000) /Lib/ld-linux.so.2 =>/lib/ld-linux.so.2 (0x40000000) As you can see, ln depends on the external shared library libc. so.6 and ld-linux.so.2. Generally, programs with dynamic links are much smaller than their equivalent programs with static links. However, programs with static links can play a role in some low-level maintenance tasks. For example, SLN is an excellent tool for modifying the symbolic links of different libraries in/lib. However, you usually find that almost all executable programs on Linux systems are variants of some kind of dynamic links. Dynamic Loader If a dynamic executable program does not contain all the functions required for running, which part of Linux is responsible for loading these programs together with all necessary shared libraries so that they can be correctly executed? The answer is dynamic loader, which is actually the ld-linux.so.2 library that you see in the LDD list of LN as a shared library relevance. The dynamic loader is responsible for loading the shared libraries required by the dynamic link executable program. Now, let's take a quick look at how the dynamic loader finds the appropriate shared library on the system. LD. So. conf The dynamic loader relies on two files-/etc/lD. So. conf and/etc/lD. So. cache to find the shared library. If you perform CAT operations on the/etc/lD. So. conf file, you may see a list similar to the following: $ CAT/etc/lD. So. conf /Usr/x11r6/lib /Usr/lib/GCC-lib/i686-pc-linux-gnu/2.95.3 /Usr/lib/Mozilla // Usr/lib/qt-x11-2.3.1/lib /Usr/local/lib The LD. So. conf file contains a list of all directories (except/lib and/usr/lib, which are automatically included in the list), and the dynamic loader searches for shared libraries. LD. So. Cache But before the dynamic loader can "see", it must be converted to the lD. So. cache file. You can do this by running the ldconfig command: # Ldconfig When the ldconfig operation ends, you will have the latest/etc/lD. So. cache file, which reflects your changes to/etc/lD. So. conf. From this moment on, the dynamic loader will view all the new directories you specified in/etc/lD. So. conf when searching for shared libraries.
Ldconfig skills To view all the shared libraries that ldconfig can "see", enter: # Ldconfig-p | less Another convenient technique can be used to configure the shared library path. Sometimes you want to tell the dynamic loader to try to use the shared library in a specific directory before trying any/etc/lD. So. conf path. This is convenient if the older application you are running cannot work with the currently installed library version. LD_LIBRARY_PATH To instruct the dynamic loader to first check a directory, set the LD_LIBRARY_PATH variable to the directory you want to search. Multiple paths are separated by colons. For example: # Export LD_LIBRARY_PATH = "/usr/lib/old:/opt/lib" After LD_LIBRARY_PATH is exported, if possible, all executable programs started from the current shell will use the libraries in/usr/lib/old or/opt/lib, if some shared library relevance requirements still cannot be met, it will be switched back to/etc/lD. so. the specified library in Conf. This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/ming470612141/archive/2008/11/22/3348063.aspx First, describe/etc/lD. So. conf: This file records the path of the dynamic link library used during compilation. By default, the compiler only uses the library files in the/lib and/usr/lib directories. If you have installed some libraries, for example, when installing GTK +-2.4.13, it will require glib-2.0 > = 2.4.0. Not Specified -- Prefix =/usr so that the glib library is installed under/usr/local, but not in/etc/lD. so. add the/usr/local/lib search path to the conf file. Therefore, compiling GTK +-2.4.13 may cause errors. In this case, there are two solutions: 1: when compiling the glib-2.4.x, specify the installation to/usr, so that the library file will be placed in/usr/lib, GTK will not find the required library file. For the installation library file, this is a good way, so you do not need to set pkg_config_path. 2. Add/usr/local/lib to/etc/lD. so. conf. Then, when installing GTK, you will search for/usr/local/lib and find the required library. Adding/usr/local/lib to/etc/lD. So. conf is also required. In this way, the problem will not occur when you install Dongdong to local. It is wise to add the paths that may store library files to/etc/lD. So. conf. The addition method is extremely simple. It is okay to directly write the absolute path of the library file into it, one line at a time. For example: /Usr/x11r6/lib /Usr/local/lib /Opt/lib Let's take a look at ldconfig: It is a program, usually located under/sbin, used by the root user. The specific functions and usage can be found in man ldconfig. To put it simply, it caches the library files in the paths listed in/etc/lD. So. conf to/etc/lD. So. cache for use. Therefore, after installing some library files (such as just installed Glib), or modifying lD. So. conf to add a new library path, run/sbin/ldconfig Make all library files cached to lD. so. cache, if not done, even if the library file is clearly under/usr/lib, it will not be used, and an error is reported during the compilation process. The xxx library is missing I have made this mistake when compiling KDE (it needs to be run once every time it is compiled), so remember to run ldconfig after modifying the library file, you can run it in any directory.
|