Generation of Linux Connection Library

Linux Connection Library generation-general Linux technology-Linux programming and kernel information. The following is a detailed description. Basic Concepts

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

To use different versions of libraries in the same system, you can add the version number as the suffix after the library file name, for example, libhello. so.1.0. Because the program connection uses. so as the file suffix by default. 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

Usage 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, indicating 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, and the header file provides the sayhello () function.

/* Hello. h */

Void sayhello ();

There are also some instructions. This typical program development kit Structure

1. Connect 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

Use the following command to connect:

$ Gcc testlib. o-lhello-o testlib

When connecting, note that libhello. o and libhello. a are both in the default library search path/usr/lib. If the-L parameter is added to other locations

2. The connection to the static database is troublesome, mainly due to 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

3. Dynamic library Path Problems

There are three methods for the execution program to smoothly find the dynamic library:

(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.

4. 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 printf

The u table symbol printf is referenced, but is 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

Generate 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 \ n ");

}

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

Connect to a static library and use the ar command. ar actually means archive.

$ Ar cqs libhello. a hello. o

2. connect to a dynamic library

Gcc is used 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 the coexistence of database files of multiple versions in the system. Normally, the name library file is the same as the soname file.

Libxxxx. so. major. minor

Xxxx indicates the database name, major indicates the main version number, and minor indicates the minor version number.