How to solve Linux dynamic library version control

Reprinted from: http://blog.csdn.net/david_xtd/article/details/7045792

(in other words, soname is not a real file, just a name saved in this library and in a file that calls this library in the future, to find the name when it is loaded, and to create a soft connection to point to the real file when used, so that the version number of the real file can be upgraded)

Linux systems also face the same problems as Windows, and how to control multiple versions of a dynamic library. Window did not deal well before, for which there is a special noun to describe the problem "Dll hell", which seriously affect the software upgrade and maintenance. Dll hell refers to the new version of the dynamic library on Windows overwrite the old version,?? But it is not compatible with the old version. Often occurs after the program upgrade, the dynamic library updates, the original program does not run up, or install new software, but the existing software does not work up. The same Linux operating system, also has the same problem, then how is it solved?

To solve this problem, Linux introduces a set of mechanisms that can be avoided if this mechanism is followed. But it's an agreement, not a compulsion. However, it is recommended to adhere to this Convention, otherwise the Linux version of the DLL Hell problem will also appear. Here is an introduction to this mechanism. The mechanism is to control the version of the DLL (shared library) through the file name.

The DLL on Linux, called the shared library, has three names, each with a different purpose.

The first is the file name (real name) of the shared library itself, which usually contains the version number, which is often the case: libmath.so.1.1.1234. Lib is the contract prefix for a library on Linux, and math is the shared library name, so is the suffix name of the shared library, 1.1.1234 is the version number of the shared library, its major version number and the minor version number +build number. The major version number, which represents the current version of the dynamic library, if the interface of the dynamic library changes, then this version number will be added 1, the following two version number (minor version and build number) is to tell you the detailed information, such as a hot-fix for a version of the build, its minor version number plus 1, The build number should also be changed. This file name contains the code for the shared library.

The second is the soname of the dynamic library (short for shared object name), which is the file name used by the application to find the shared library when it loads the DLL. Its format is

Lib + math+.so + (major version number)

It contains only major version number, in other words, the application can be used whenever its interface is not changed, regardless of whether you subsequently minor build version or build version.

The question comes, how to find a real name by Soname when the program runs? Where does Soname exist? If you are associated with real name? When did you save it?

This is the name of the third shared library to be introduced next, link name, as the name implies, is the file name used in the compile process, link phase. It associates soname with the real name.

The third name, the connection name for the shared library, is the name used specifically for the build phase connection. The name is lib + math +.so, such as libmath.so. It is not with any version information. During the connection phase during the shared library compilation process, the compiler generates a shared library and real name, while the soname of the shared library is written in the file header of the shared library file. You can use the command readelf-d sharelibrary to view.

When an application references a shared library, it uses the link name of the shared library. In the application link phase, it finds the dynamic library through the link name, and extracts the soname of the shared library and writes it to the header file of its own shared library. When the application loads, it looks for the shared library by Soname to the given path.

The code below illustrates how the system is done and describes some of the system's facilities and tools:

Code:? 1. File libhello.c

/* Hello.c-demonstrate library use. */

#include <stdio.h>

void Hello (void)

{printf ("Hello, library world./n");}

2. File libhello.h

/* Libhello.h-demonstrate library use. */

void Hello (void);

3. File MAIN.C

/* MAIN.C--demonstrate direct use of the "hello" routine */

#include "hello.h"

int main (void)

{

Hello ();

return 0;

}

1. Generate a shared library, associated with real name and Soname.

Gcc-g-wall-fpic-c Hello.c-o hello.o

Gcc-shared-w,soname,-libhello.so.0-o libhello.so.0.0.0 hello.o

The shared library libhello.so.0.0.0 will be generated.

You can view the header of a shared library with a system-provided tool:

Readelf-d libhello.so.0.0.0 | grep Libhello

ox00000000000e (SONAME) library SONAME: [libhello.so.0]

2. Applications, referencing shared libraries.

The link name is generated manually before being linked by the following program

Ln-s libhello.so.0.0.0 libhello.so.0

Gcc-g-wall-c main.c-o main.o-i.

Gcc-o main main.o-lhello-l.

To view the compiled program:

readelf-d Main | grep Libhello

OX000000000001 (NEEDED) shared library: [libhello.so.0]

To run the program, you need to specify the path to the shared library. There are two ways to use the environment variable "Ld_library_path" in the first case. One way to do this is to copy the shared library to the system directory (one of the directories specified by the PATH environment variable).

Time out! We have not solved a problem is that the program only know Soname, how to find the shared library from Soname, that is, the real name file? This requires that we define a link file to connect to the shared library itself.

Ln-s libhello.so.0.0.0 libhello.so.0

Of course, this path needs to be placed in the LD_LIBRARY_PATH environment variable.

This allows you to run the program.

[Note] The Linux system provides a command LDCONIFG specifically for generating soname files for shared libraries so that the program can find shared libraries through soname after loading. At the same time, the command also to speed up the loading of shared libraries, the system's shared library into a cache file, which can improve the search speed. You can use the following command to look at the system's existing cached shared libraries.

Ld-p

3. Shared library, minor version upgrade, that is, the interface is unchanged.

When you upgrade a iteration, the soname of the shared library is constant, so you need to re-specify the new version of the Soname connection file. Call the Ldconfig command and the system will help you modify that soname link file and point it to the new version. Your application will be upgraded automatically at this time.

4. Shared library, major version upgrade, that is, the interface has changed.

When the major version is upgraded, the soname of the shared library will be added 1. For example, libhello.so.0.0.0 becomes libhello.so.1.0.0. When you run the Ldconfig file again, you will find that two connection files are generated.

Ln-s libhello.so.0---->libhello.so.0.0.0

Ln-s libhello.so.1----->libhello.so.1.0.0

Although the shared library is upgraded, your program still uses the old shared library, and the two does not affect each other.

The problem is that if the updated shared library only adds some interfaces, it does not modify the existing interface, which is forward compatible. But this time its main version number was increased by 1. What if your application wants to invoke a new shared library? Simply, just manually modify the Soname file so that it points to the new version. (This time Ldconfig file will not help you do such a thing, because this time soname and real name version number of the motherboard is inconsistent, can only be manually modified).

For example: Ln-s libhello.so.0---> libhello.so.1.0.0

However, there are times when the major version number increases, the interface changes, and may be forward incompatible. At this time again such a modification, will be error, "XX" method can not find such errors.

To summarize, the Linux system manages multiple versions of a shared library by sharing three different names for the library. Real name is the actual file name of the shared library, and Soname is the file name used when the shared library is loaded. When building a shared library, the compiler binds the soname to the file header of the shared library. When the application references a shared library, it is done through link name, and link will search for the link name in the directory specified by the system to find the shared library and write the soname of the shared library in the application's header file. When the application loads the shared library, it looks for the shared library through Soname in the system-specified directory (path or ld_library).

When a shared library is upgraded, it is divided into

Two kinds. One is the motherboard unchanged, the upgrade iteration and build number. In this case, the system will use the new version number by updating Soname (Ldconfig to maintain). In this case, the old version is useless and can be deleted.

The other is the main version upgrade, which means that the library interface changes, of course, this time can not overwrite the existing soname. The system makes the new and old versions exist by adding a soname (ldconfig-p). The original application, when loading, is still looking for old library files based on the old soname of their header files.

5. What happens if the soname of the shared library is not specified when compiling?

This is a trick place. The first system will have no soname placed in the library's head when the library is built. When the application connects, the linkname is placed in the application-dependent library. Or in other words, Soname does not have a version number at this time. Sometimes someone directly use this to upgrade the application, for example, the new version of the library, directly copied to the system directory, will overwrite the existing old library files, directly upgrade. This gives the programmer a great degree of convenience, and if one step is careful, it will be transferred to the Windows-like DLL Hell trap. It is recommended that you do not do so.

"Note"

1. Specify the path that the shared library loads. The Ld_library_path takes precedence over the PATH environment variable.

2. LDD can view the program, or the path of the library to which the shared library depends

3. NM View shared library exposed interfaces

4. Ldconfig can automatically generate Soname connection files. and provides catch-accelerated lookups.

5.readelf can view the information of the dynamic library, such as the dependent library, its own soname.

6. Objdump is similar to readelf.

7 LD the GUN linker

8. LD.SO Dynamic linker or loader

9. As the portable GNU Assembley

"Reference"

Http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

How to troubleshoot Linux Dynamic library versioning