Analysis of static and dynamic libraries in Linux

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. database used

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 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 library but not defined in the Library (indicating that it needs to be supported by other libraries), which 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" symbol, although they are defined in the library, however, it may be overwritten by symbols of the same name in other databases, 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 see where printf is ultimately 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. during compilation, you can use any full-coding parameters, such as adding-G to the debugging code:

Gcc-C hello. C-O hello. o

1. connect to a static database and use the AR command to connect to a static database. 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 it is finding such a name in the library, 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.