Analysis and use of dynamic shared link libraries in Linux

Article Title: analysis and use of dynamic shared link libraries in Linux. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

The dynamic shared library works differently from the static Linked Library. For each application that uses a static Link Library, there is a static link library copy in the application. However, the dynamic shared library is not like this. The dynamic shared library is shared by all applications that use it, no matter how many processes call a dynamic shared library, the system always runs only one dynamic shared library. Here, the meaning of "sharing" in the dynamic shared library is as follows. As for "dynamic", the main emphasis is on the phase at which the link occurs. For the static Link Library, the link process occurs in the compilation phase, and the operating system does not make any changes to the program when loading the program, so the "static" link; however, for programs that use dynamic shared libraries, the compiler only knows the program when compiling the program.

A symbol to be used in a dynamic shared library. The entity corresponding to this symbol is unknown during compilation. The conversion from a symbol to an object is left to the support of the operating system when the program is loaded. In essence, such a conversion process is to delay the link process of the program until it is executed. This is obviously different from completing the link detonator during compilation. This is why the dynamic shared library is named "dynamic.

Dynamic shared libraries have the following advantages, making them more popular in Linux development than static linked libraries.

(1) memory saving

No matter how many applications are using the dynamic shared library, there is only one copy of the dynamic shared library in the memory. Unlike the static Linked Library, a static chain is used in the running of an application.

When the database is connected, there will be copies of Multiple Static linked databases.

(2) disk saving

This is similar to memory saving. It is also caused by the copy of the static link inventory in Multiple Static link libraries. For the same application, the version compiled using the dynamic shared library is usually smaller than the version compiled using the static Link Library. Therefore, the use of dynamic shared libraries in embedded system development does not save space, providing a good choice.

(3) Easy software repair and upgrade

Because dynamic sharing exists independently of applications, it is very easy to replace the old version with the new version of dynamic sharing library. If a static link library is used and a bug is found in a static library, you need to re-compile all applications that use the static library to correct the bug, if there are a lot of applications using this static library, you can imagine the workload.

(4) Improve Performance

Compared with applications that use static linked libraries, applications that use dynamic shared libraries are much more "slim", so when the operating system loads applications

Copy to memory, this "slim" Dynamic Link Library also has a great advantage, while improving the performance of the program.

Of course, the dynamic link library also has the following Disadvantages while having these advantages. Complexity, compatibility, and debugging difficulties. However, it is still more frequently used in Linux than the static Link Library. More widely used.

An important concept of dynamic shared library ----- soname

A dynamic shared library has an important concept-soname. A dynamic shared library exists as a file in Linux. In this way, each dynamic shared library has a file name. Assume that the file name of the dynamic shared library is defined as filename. One thing to remember is that soname and filename are not concepts. In Linux, each dynamic shared library must be assigned a specific name. The Linux document calls it soname. Soname usually contains the name and version number of the shared library. A dynamic shared library can be uniquely identified by the soname, system, or linker. For example, in Linux, The soname of the c function library is libc. so.6. Here, c is the name of the function library, and 6 is the version number of the dynamic shared library.

However, the application is not directly linked to a file named soname. For example, for Linux C library, although the file named libc. so.6 can be found in the system, this file is actually just a soft connection, that is, a symbolic link. Here it is clearly displayed that libc. so.6 is a soft connection to the libc-2.3.2.so. Then, this soft connection is established by ldconfig. Ldconfig is used to configure the runtime binding of the dynamic linker. For a compiled dynamic link library, how does one know its soname? You can use readelf. Readelf has an option-d, which can print the content of the dynameic segment in the ELF File. The dynamic segment in ELF contains the soname of the dynamic shared library. There is a file/etc/ld. so. conf in Linux. Each row in this file specifies the directory that ldconfig should search for. Under these directories, the dynamic shared library files required for running the system are stored. so. x. the files at the end of x; ldconfig searches for these directories in sequence to create a soft link to the total soname for each dynamic shared library file found.

Build and install a dynamic shared library

When compiling the target file for a dynamic shared library, the following options of the GCC compiler are required:

-Share: This option tells GCC to generate a shared target file. The generated shared target file can be linked with other target files to form an executable file. This option must be used together with options such as-fPIC.

-FPIC: This option tells GCC to generate Position-Independent Code (PIC) and use Position-Independent Code in the shared library.

-Wl,-soname, xxx: this is a special GCC option. With this option, GCC will pass-soname, xxx as a command line option to the linker ld. What does ld do with this option? There is a soname item in the dynamic segment of each dynamic shared library. -Soname: the xxx option tells the linker ld that the file to be linked is a dynamic shared library, and its soname is xxx. for example, if you compile a Linux C library with version 6, you should specify the link option-Wl,-soname, libc for GCC when generating the libc-2.3.2.so. so.6.

The last step to build a dynamic shared library is usually the following command line:

Gcc-share-Wl, soname, xxx-o libname filelist liblist

In this command line, libname indicates the final file name of the dynamic shared library. For example, a libc-2.3.2.so.filelist is a list of target files, which indicate which compiled target files will be placed in the final dynamic shared library. Because the dynamic shared library can depend on other shared libraries, this item specifies the list of shared libraries that the final generated dynamic shared library will depend on.

After the dynamic shared library is built, if you need to install it in a specific and system directory (for example, the most common/usr/local/lib directory ), you only need to copy the dynamic shared library file to the corresponding directory. Run ldconfig to create a soft connection named after soname, provided that the directory of the shared library is included in/etc/ld. so. in the conf file, to enable the linker to connect to the dynamic shared library in a standard way, you also need to create a soft connection without a version number. We can see that there are a lot of. so. XX files under the lib directory of the Linxu system. This is the dynamic shared library used in the system.

Here we can see that libc. so.6. this is the C function library file in linux. We can see that this is a symbolic link, the real file is libc-2.10.2.so.

# Lib $ ls-l libc. so.6

Lrwxrwxrwx 1 root 14 2009-12-09 20:59 libc. so.6-> libc-2.10.1.so

# Lib $ readelf-d libc-2.10.1.so

Dynamic section at offset 0x168b40 contains 26 entries:

Tag Type Name/Value

0x0000000000000001 (NEEDED) Shared library: [ld-linux-x86-64.so.2]

0x000000000000000e (SONAME) Library soname: [libc. so.6]

0x000000000000000c (INIT) 0x1e7b0

0x000000000000001a (FINI_ARRAY) 0x365740

0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)

0x0000000000000004 (HASH) 0x1620d8

0x000000006ffffef5 (GNU_HASH) 0x2b8

0x0000000000000005 (STRTAB) 0x10560

0x0000000000000006 (SYMTAB) 0x3c00

0x000000000000000a (STRSZ) 21963 (bytes)

0x000000000000000b (SYMENT) 24 (bytes)

0x0000000000000003 (PLTGOT) 0x0000fe8

0x0000000000000002 (PLTRELSZ) 192 (bytes)

0x0000000000000014 (PLTREL) RELA

0x0000000000000017 (JMPREL) 0x1e5d8

0x0000000000000007 (RELA) 0x16e38

0x0000000000000008 (RELASZ) 30624 (bytes)

0x0000000000000009 (RELAENT) 24 (bytes)

0x000000006ffffc (VERDEF) 0x16bf8

0x000000006ffffffd (VERDEFNUM) 15

0x000000000000001e (FLAGS) STATIC_TLS

0x000000006ffffffe (VERNEED) 0x16e08

0x000000006fffffff (VERNEEDNUM) 1

0x000000006ffffff0 (VERSYM) 0x15b2c

0x000000006ffffff9 (RELACOUNT) 1190

0x0000000000000000 (NULL) 0x0

The following uses the foo. c and bar. c files as examples: How to build a dynamic shared library

#:~ /Program $ gcc-fPIC-g-c-o foo. o foo. c

#~ /Program $ gcc-fPIC-g-c-o bar. o bar. c

#:~ /Program $ gcc-shared-g-Wl,-soname, libfoobar. so.0-o libfoobar. so.0.0 foo. o bar. o-lc

#:~ /Program $ sudo cp libfoobar. so.0.0/usr/local/lib

#:~ /Program $ sudo ldconfig

#:~ /Program $ cd/usr/local/lib

#:/Usr/local/lib $ ls

Libfoobar. so.0 libfoobar. so.0.0 python2.6

#:/Usr/local/lib $ ln-sf libfoobar. so.0 libfoobar. so

Ln: creating symbolic link 'libfoobar. so': Permission denied

#:/Usr/local/lib $ sudo ln-sf libfoobar. so.0 libfoobar. so

#:/Usr/local/lib $

#:~ /Program $ gcc-g-o foobar main. c-lfoobar

#:~ /Program $./foobar

This is foo! Library2 is

Foo () = foo

This is library1 is called

Bar () = bar

Here, the soname of the shared library is specified as libfoobar. so.0, the final dynamic shared library file is libfoobar. so.0.0, foo. o and bar. o is to be placed in libfoobar. so.0 -. the target file list in 0, and-lc is libfoobar. the list of shared libraries on which so.0.0 depends. Only one Linux C library is dependent. Next, set libfoobar. so.0.0 is installed in the/usr/local/lib directory, and then ldconfig is run. In addition, to allow the linker to link libfoobar. so.0.0 and create a file pointing to libfoorbar. so.0 is connected with the symbol.

This section briefly analyzes the use of Linux dynamic shared libraries and makes a record for future use.