LPI101-Topic102 of ibm lpi review material: Linux installation and package management (3) Managing Dynamic Link Libraries (finding and loading dynamic link library files required by programs)

This topic describes how to find and load dynamic libraries required by Linux applications. Specifically:

• Determine the library files required by the program
• How does the system find shared library files?
• Load shared library files

This article helps readers prepare the 102.3 goal in lpi101 with a weight of 1. There are two types of executable programs in static and dynamic link Linux systems:

• Static link executable program. This program file contains the code for running all library functions required. The program itself can run without relying on additional library files. One advantage of statically linked programs is that no additional dependent libraries are required for installation.
• Dynamic Link executable program. The Dynamic Linking program only sets placeholders for the called library functions, and does not really link the function code to the program itself, so this program is small in size. In addition, multiple programs often rely on the same shared library file. When multiple programs run, the physical memory needs to retain a shared library code through the virtual memory mechanism, greatly saves memory space. Its disadvantage is that it depends on the external library file for its own operation. If the library file on which it depends does not exist during installation, additional library files need to be installed. In general, the advantage is greater than the disadvantage, so most programs on the system are dynamically linked.

There is an interesting example in many Linux systems: The/bin/ln command. This command is used to create soft links or hard links (note that the link here is different from the dynamic link of the program ). The ln program is also dynamically linked, so its running depends on the dynamic loading mechanism. Dynamic Loading relies on this symbolic link mechanism because symbolic links are often used when loading dynamic libraries (for example, using the ls-linux-86-64.so.2 symbolic link instead of the real file ld-2.11.1.so. What should I do if this soft link is faulty or deleted? The solution is to recreate one. Now the problem arises. The ln command is used to create a link file for dynamic loading, and the dynamic loading of LN itself during runtime may depend on the problematic symbolic link, this is prone to endless loops. To solve this problem, some Linux releases provide additional ln static link version SLN. Fedora12
The two files in the 64bit system are as follows: Listing 1. Sizes of SLN and LN

[ian@echidna ~]$ ls -l /sbin/sln /bin/ln-rwxr-xr-x. 1 root root 47384 2010-01-12 09:35 /bin/ln-rwxr-xr-x. 1 root root 603680 2010-01-04 09:07 /sbin/sln

It can be seen that the file size is much larger when static links of the same program are linked.

What library files are required? Although the LPI test does not require this topic, you should still know that the machines in many Linux systems can support 32-bit and 64-bit programs at the same time. Therefore, many library files have both 32-bit and 64-bit versions. The 64-bit version is stored in the/lib64 directory, and the 32-bit version is stored in/lib. You are likely to find both the/lib/libc-2.11.1.so and/lib64/libc-2.11.1.so library files in a typical 64-bit Linux system. In addition to knowing the size of a static link file, can you tell whether a program is a static link or a dynamic link? If it is a dynamic link, do you know which library files it depends on? The LDD command can help you answer these two questions. If you are running a system like Debian or Ubuntu, you may not be able to find the SLN program. You also need to check whether/sbin/ldconfig exists. In this example, the fedora12 64-bit system is used. For comparison, the output on the 32-bit system is also listed. Listing 2. Output lddFor
SLN and LN

[ian@echidna ~]$ #Fedora 12 64-bit[ian@echidna ~]$ ldd /sbin/sln /sbin/ldconfig /bin/ln/sbin/sln: not a dynamic executable/sbin/ldconfig: not a dynamic executable/bin/ln: linux-vdso.so.1 => (0x00007fff644af000) libc.so.6 => /lib64/libc.so.6 (0x00000037eb800000) /lib64/ld-linux-x86-64.so.2 (0x00000037eb400000)[ian@pinguino ~]$ # Fedora 8 32-bit[ian@pinguino ~]$ ldd /bin/ln linux-gate.so.1 => (0x00110000) libc.so.6 => /lib/libc.so.6 (0x00a57000) /lib/ld-linux.so.2 (0x00a38000)

The function of the LDD command is to view the dynamic link information. For static link programs such as SLN and ldconfig, only the prompt "not a dynamic executable" is displayed ". Three dynamic link library files are provided for Dynamic Link ln files .. So extension name is shared object, also known as dynamic link library. The above output also shows three different types of dependent files:

• The linux-vsdo.so.1 is a Linux virtual dynamic shared object, which we will talk about later. In fedora8, It is a linux-gate.so.1.
• Libc. so.6 points to/lib64/libc. so.6
• /Lib64/The ld-linux-x86-64.so.2 is the absolute path to a library file

In the following table, the LS-l command shows that the last two library files above are actually symbolic links of the specific version library files. In the fedora12 system, the result is as follows: Listing 3. Library Symbolic Links

[ian@echidna ~]$ ls -l /lib64/libc.so.6 /lib64/ld-linux-x86-64.so.2lrwxrwxrwx. 1 root root 12 2010-01-14 14:24 /lib64/ld-linux-x86-64.so.2 -> ld-2.11.1.solrwxrwxrwx. 1 root root 14 2010-01-14 14:24 /lib64/libc.so.6 -> libc-2.11.1.so

In the early x86 era, the communication between user programs and kernel space programs was interrupted by software. As the processor speed increases, this method has become a serious bottleneck. Since Pentium II, Intel introduced a mechanism called fast system call to accelerate the execution of system calls. This new method uses dedicated sysenter and sysexit commands instead of interruption. The linux-vdso.so.1 mentioned above is a virtual library file or virtual dynamic shared object that resides in the address space of each program process. The file name in the old system is a linux-gate.so.1. This virtual library provides the necessary logic to allow your program to select the fastest way to call system functions on a specific processor, which may be soft interruptions, however, in most new CPUs, fast system call is used. Dynamic Loading may surprise you, as mentioned above/lib/ld-linux.so.2 as well as its 64-bit version/lib64/ld-linux-x86-64.so.2 although it looks like a shared library file, but actually they can run independently. Their functions are responsible for dynamic loading. They read the header information of executable files to determine which database files are required and which files need to be loaded. After the script is loaded, it modifies the address pointer in the execution file to dynamically link the loaded library file. Then the program can run. The help manual for the ld-linux.so also describes the lD. So file, which targets early executable programs in A. Out format. The -- list parameter of the ld-linux.so.2 displays the same information as the LDD command, as shown in the following table: Listing 4. Using ld-linux.so to display library requirements

[ian@echidna ~]$ /lib64/ld-linux-x86-64.so.2 --list /bin/ln linux-vdso.so.1 => (0x00007fffc9fff000) libc.so.6 => /lib64/libc.so.6 (0x00000037eb800000) /lib64/ld-linux-x86-64.so.2 (0x00000037eb400000)[ian@pinguino ~]$ /lib/ld-linux.so.2 --list /bin/ln linux-gate.so.1 => (0x00110000) libc.so.6 => /lib/libc.so.6 (0x00a57000) /lib/ld-linux.so.2 (0x00a38000)

Note: The preceding address may be different for each operation. The dynamic library configuration can read the dependent library file information from the executable file header. Where can the dynamic loader find these library files? In the Linux world, there is a configuration file to describe the information. In fact, there are two configuration files:/etc/lD. So. conf and/etc/lD. So. cache. The following table shows the content of/etc/lD. So. conf. Note that the/etc/lD. So. conf file specifies that all configuration files under the lD. So. conf. d directory will be included. The/etc/lD. So. conf file on the old system may contain many configuration items rather than loading configuration items from sub-directories. Listing 5. Content of/etc/lD. So. conf

[ian@echidna ~]$ cat /etc/ld.so.confinclude ld.so.conf.d/*.conf[ian@echidna ~]$ ls /etc/ld.so.conf.d/*.conf/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.19.fc12.x86_64.conf/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.22.fc12.x86_64.conf/etc/ld.so.conf.d/kernel-2.6.31.12-174.2.3.fc12.x86_64.conf/etc/ld.so.conf.d/mysql-x86_64.conf/etc/ld.so.conf.d/qt-x86_64.conf/etc/ld.so.conf.d/tix-x86_64.conf/etc/ld.so.conf.d/xulrunner-64.conf

The program loading speed is very important, so use the ldconfig command to process lD. so. CONF file and other configuration files contained in it, as well as library files under the/lib,/usr/lib directory, and other library files provided in the form of command line parameters. Ldconfig is used to create necessary symbolic links and cache information for recently used library files, and write the/etc/lD. So. cache file. The dynamic loader uses the information in the/etc/lD. So. cache file to find and load the library file. If you change the lD. So. conf file or its sub-files, you must run the ldconfig command again to update the/etc/lD. So. cache file. Normally, you can use the ldconfig command without any parameters to recreate the lD. So. cache file. You can also provide commands for ldconfig to change this default behavior. Generally, man ldconfig is used to view more information. The following table shows how to use the-p parameter to view the content in LD. So. cache. Listing 6. Using ldconfig to display lD. So. Cache

[ian@lyrebird ian]$ /sbin/ldconfig -p | less1602 libs found in cache `/etc/ld.so.cache' libzip.so.1 (libc6,x86-64) => /usr/lib64/libzip.so.1 libz.so.1 (libc6,x86-64) => /lib64/libz.so.1 libz.so (libc6,x86-64) => /usr/lib64/libz.so libx86.so.1 (libc6,x86-64) => /usr/lib64/libx86.so.1 libx11globalcomm.so.1 (libc6,x86-64) => /usr/lib64/libx11globalcomm.so.1 libxul.so (libc6,x86-64) => /usr/lib64/xulrunner-1.9.1/libxul.so libxtables.so.2 (libc6,x86-64) => /usr/lib64/libxtables.so.2 libxslt.so.1 (libc6,x86-64) => /usr/lib64/libxslt.so.1 libxslt.so (libc6,x86-64) => /usr/lib64/libxslt.so libxpcom.so (libc6,x86-64) => /usr/lib64/xulrunner-1.9.1/libxpcom.so libxml2.so.2 (libc6,x86-64) => /usr/lib64/libxml2.so.2 libxml2.so (libc6,x86-64) => /usr/lib64/libxml2.so ... libABRTdUtils.so.0 (libc6,x86-64) => /usr/lib64/libABRTdUtils.so.0 libABRTUtils.so.0 (libc6,x86-64) => /usr/lib64/libABRTUtils.so.0 ld-linux.so.2 (ELF) => /lib/ld-linux.so.2 ld-linux-x86-64.so.2 (libc6,x86-64) => /lib64/ld-linux-x86-64.so.2

Load the specified library file. If you are running an application that relies on the shared library file of a specific old version, or you are developing and testing a new shared library or a new version of the shared library, you need to use the default search path of the loader. This need also appears in the script that uses a specific product shared library. This specific product shared library may be installed in the/OPT directory. Just as you can change the path environment variable to specify the search path of the executable program, you can modify the LD_LIBRARY_PATH environment variable to modify the search path of the dynamic loader. The path specified by LD_LIBRARY_PATH is placed before the path in the lD. So. cache file. For example, you may use the following commands:

export LD_LIBRARY_PATH=/usr/lib/oldstuff:/opt/IBM/AgentController/lib