Analysis of Linux static and dynamic libraries

Basic Concepts

There are two types of libraries: Dynamic and Static. Dynamic files are usually suffixed with. so, and static files are suffixed with..

For example: libhello. so libhello. to use libraries of different versions in the same system, you can add the version number suffix after the library file name, for example, libhello. so.1.0, because the program connection defaults. so is the file suffix. To use these libraries, we usually use the symbolic connection method.

Ln-s libhello. so.1.0 libhello. so.1

Ln-s libhello. so.1 libhello. so 1. Use the library

When you want to use a static library, the connector will find the functions required by the program and then copy them to the execution file. Because this copy is complete, once the connection is successful, static libraries are no longer needed. However, this is not the case for dynamic libraries. The dynamic library will leave a flag in the execution program to indicate that when the program is executed, the library must be loaded first. Because the dynamic library saves space, the default operation for linux connection is to connect to the dynamic library first. That is to say, if both static and dynamic libraries exist, will be connected to the dynamic library. Now suppose there is a program development kit named hello, which provides a static library libhello. a dynamic library libhello. so, a header file hello. h. The header file provides the sayhello () function/* hello. h */void sayhello (); there are also some instructions.

This typical program development kit structure is connected to the dynamic library by default. linux is connected to the dynamic library. The following program testlib. c uses the sayhello () function in the hello library.

/* Testlib. c */

Include <>

Include <>

Int main ()

{

Sayhello ();

Return 0;

}

Use the following command to compile $ gcc-c testlib. c-o testlib. o

Run the following command to connect: $ gcc testlib. o-lhello-o testlib

Note the following when connecting to libhello. o and libhello. a is in the default library search path/usr/lib. If you need to add the-L parameter to other locations to connect to the static library, it is troublesome, mainly because of parameter issues. Or the above example:

$ Gcc testlib. o-o testlib-WI,-Bstatic-lhello

Note: This special "-WI,-Bstatic" parameter is actually transmitted to the connector ld. Indicates that it is connected to the static database. This parameter is not required if only the static database is in the system. If you want to connect multiple databases, and the connection methods for each database are different, for example, the above program requires both static connection with libhello and dynamic connection with libbye, the command should be:

$ Gcc testlib. o-o testlib-WI,-Bstatic-lhello-WI,-Bdynamic-lbye

2. The path of the dynamic library has three methods to make the execution program find the dynamic library smoothly:

(1) copy the database to the/usr/lib and/lib directories.

(2) Add the path of the library in the LD_LIBRARY_PATH environment variable.

For example, if the dynamic library libhello. so is in the/home/ting/lib directory and bash is used as an example, run the following command:

$ Export LD_LIBRARY_PATH = $ LD_LIBRARY_PATH:/home/ting/lib

(3) modify the/etc/ld. so. conf file, add the path of the Library to the end of the file, and execute ldconfig refresh. In this way, all the library files under the added directory are visible.

3. view the symbols in the library

Sometimes you may need to check the functions in a library. The nm command can print all the symbols involved in the library. The database can be static or dynamic. There are many symbols listed in nm, and there are three common ones:

One is called in the database, but is not defined in the database (indicating that other databases are required for support), and is displayed in the utable;

One is the function defined in the library, represented by T, which is the most common;

The other is the so-called "weak state" symbols. Although they are defined in the library, they may be overwritten by the same name symbols in other libraries, which are represented by W.

For example, if the developer wants to know whether printf () is defined in the hello Library mentioned above ():

$ Nm libhello. so | grep printf U

The printf u ing symbol printf is referenced but not defined in the function. It can be inferred that to use the hello library normally, it must be supported by other libraries, run the ldd command to check which libraries hello depends on:

$ Ldd hello libc. so.6 =>/lib/libc. so.6 (0x400la000)/lib/ld-linux.so.2 =>/lib/ld-linux.so.2 (0x40000000)

From the above results, you can continue to check where printf is defined. If you are interested, go on

4. Generate a database

The first step is to compile the source code into the target code.

The following code is used as an example to generate the hello library used above:

/* Hello. c */

Include <>

Void sayhello ()

{

Printf ("hello, world ");

}

Compile the file with gcc. You can use any full-coding parameters when compiling the file, for example, adding-g to the debugging code: gcc-c hello. c-o hello. o

(1) connecting to a static database and connecting to a static database using the ar command. ar actually means archive.

$ Ar cqs libhello. a hello. o

(2) Use gcc to connect to a dynamic library to generate a dynamic library. because there may be multiple versions, the version number is usually specified:

$ Gcc-shared-Wl,-soname, libhello. so.1-o libhello. so.1.0 hello. o

In addition, two symbolic connections are established:

$ Ln-s libhello. so.1.0 libhello. so.1

$ Ln-s libhello. so.1 libhello. so

In this way, the dynamic Connection Library of libhello is generated. The most important thing is to pass the gcc-shared parameter so that it is generated as a dynamic library rather than a common execution program. -Wl indicates that the following parameter is-soname, and libhello. so.1 is directly transmitted to the connector ld for processing. In fact, each database has a soname. When the connector finds that the library It is searching for has such a name, the connector will embed the soname into the binary file in the link, instead of the actual file name it is running, during program execution, the program will find the file with the soname name, rather than the file name of the library. In other words, soname is the identification mark of the library. The main purpose of this operation is to allow coexistence of library files of multiple versions in the system. It is customary that libxxxx is usually the same as soname when naming library files. so. major. in minor, xxxx indicates the database name, major indicates the main version number, and minor indicates the minor version number.

Summary

Through the analysis of the LINUX library, we can understand how to find the "library" in other places while the program is running. In the next article, I will continue to study the execution process of executable programs, writing a script on the server over the past two days is almost successful. The time spent on Linux is obviously a little less. After two days, after the development of the applet, it will immediately go back to the right line.