How to Implement Version Control for shared libraries in Linux

How to Implement Version Control for shared libraries in Linux

Linux systems also face the same issues as windows, and how to control multiple versions of dynamic libraries. Windows was not well handled before. Therefore, we have a special term to describe this problem "DLL hell", which seriously affects software upgrade and maintenance. DLL hell indicates that the new version of the dynamic library on Windows overwrites the old version, but it is not compatible with the old version. Often occurs inProgramAfter the upgrade, the dynamic library is updated, and the original program cannot run; or new software can be installed, but the existing software cannot run. In the same way as in Linux, how does one solve the same problem?

Linux introduces a mechanism to solve this problem. If you follow this mechanism, you can avoid this problem. But this is only an agreement, not mandatory. However, we recommend that you follow this Convention. Otherwise, the Linux version of DLL hell may also occur. Next we will introduce this mechanism. This mechanism controls the DLL (shared library) version through the file name.

Linux DLL, called shared library, has three different names for different purposes.

The first is the file name (real name) of the shared library, which usually contains the version number. This is often the case with libmath. so.1.1.1234. Lib is the agreed prefix of the library on Linux, math is the shared library name sub-, so is the extension of the shared library, 1.1.1234 is the version number of the shared library, its main version number + minor version number + build number. The main board number indicates the version of the current dynamic library. If the interface of the dynamic library changes, add 1 to the version number. The two later versions (minor version number and build number) is to tell you the detailed information, such as a version generated for a hot-fix, its minor version number plus 1, the build number should also change. The file name containsCode.

The second is the soname (short for shared object name) of the dynamic library. It is the file name used by the application to find the shared library when loading the DLL. The format is

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

It only contains the major version number. In other words, as long as the interface is not changed, the application can be used, regardless of your subsequent minor build version or build version.

The question is, how can I find a real name through soname when running the program? Where does soname exist? If it is associated with real name? When is it stored?

This is the name of the third shared library to be introduced next. Link name, as the name suggests, is the file name used in the Link phase during the compilation process. It associates sonmae with real name.

The third name is the connection name of the shared library, which is used specifically for the build Stage connection. This name is lib + math +. So, for example, libmath. So. It does not contain any version information. During the compilation process of the shared library, in the Link phase, the compiler generates a shared library and a real name, and writes the soname of the shared library in the file header of the shared library file. You can run the readelf-D sharelibrary command to view the information.

When an application references a shared library, it uses the Link name of the shared library. In the link stage of an application, it finds a dynamic library by Link name, extracts the soname of the shared library, and writes it in the header of its own shared library. When an application is loaded, it uses soname to find the shared library in the specified path.

The following code illustrates how the system is implemented and introduces some system 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 and associate it 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.

You can use the tools provided by the system to view the header of the Shared Library:

Readelf-D libhello. so.0.0.0 | grep libhello

Ox100000000000e (soname) Library soname: [libhello. so.0]

2. The application references the shared library.

Manually generate the Link name to be linked by subsequent programs.

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

Gcc-g-wall-C main. C-o main. O-I.

Gcc-O main. O-lhello-L.

View the compiled program:

Readelf-D main | grep libhello

Ox1000000000001 (needed) Shared Library: [libhello. so.0]

To run this program, you must specify the path of the shared library. There are two methods. The first method is to use the environment variable "LD_LIBRARY_PATH". The other method is to copy the Shared Library to the system directory (one of the directories specified by the PATH environment variable ).

Pause! One problem we haven't solved yet is that the program only knows soname. How can we find the shared library, that is, the real name file, from soname? We need to 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 must be placed in the LD_LIBRARY_PATH environment variable.

In this way, you can run the program.

[Note] the Linux system provides the command ldconifg to generate a soname file for the shared library, so that the program can find the shared library through soname after loading. At the same time, this command also accelerates the loading of shared libraries and puts the system shared libraries into a cache file, which can improve the search speed. You can run the following command to check the existing shared library cached by the system.

LD-P

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

When upgrading a minor version, the soname of the Shared Library remains unchanged. Therefore, you need to specify the connection file of the soname to a new version. By calling the ldconfig command, the system will help you modify the soname link file and direct it to a new version. At this time, your application will be automatically upgraded.

4. Shared Library, Master version upgrade, that is, the interface changes.

When the master version is upgraded, the soname of the shared library will be added with 1. For example, if libhello. so.0.0.0 is changed to libhello. so.1.0.0. then run the ldconfig file and generate two connection files.

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

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

Despite the upgrade of the shared library, your program still uses the old shared library, and the two will not affect each other.

The problem is that if the updated Shared Library only adds some interfaces and does not modify the existing interfaces, that is, forward compatibility. However, the primary version number is increased at this time. 1. What if your application wants to call a new shared library? Simple: you only need to manually modify the soname file to point it to a new version. (At this time, the ldconfig file will not help you do this, because at this time, the soname and the real name version number of the main board are inconsistent, you can only manually modify ).

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

However, when the main version number increases and the interface changes, it may be backward incompatible. At this time, an error will be reported if the "XX" method cannot be found.

To sum up, the Linux system manages multiple versions of the shared library by sharing the three different names of the library. Real name is the actual file name of the shared library, and soname is the file name used for loading the shared library. When a shared library is generated, the compiler binds the soname to the file header of the shared library and associates the two. When an application references a shared library, it uses the Link name to complete the process. During the link process, the shared library is searched for by Link name based on the directory specified by the system, and write the soname of the shared library in the header file of the application. When an application loads the shared library, it searches for the shared library through the path or ld_library specified by the system by soname.

When the shared library is upgraded, there are two types. One is that the motherboard version remains unchanged. Upgrade the minor version and build number. In this case, the system updates the soname (ldconfig for maintenance) to use the new version number. In this case, the old version is useless and can be deleted.

The other is the upgrade of the main version, which means that the library interface changes. Of course, the existing soname cannot be overwritten at this time. The system adds a soname (added in ldconfig-p) so that the new and old versions coexist. When loading the original application, you still need to find the old library file based on the old soname of the header file.

5. What if the soname of the shared library is not specified during compilation?

This is a trick place. First, the system will not put the soname into the database header when the database is generated. Therefore, when the application is connected, the linkname is put into the application dependency library. Or in other words, soname does not contain the version number. Sometimes someone directly uses this to upgrade the application. For example, if the new version of the database is directly copied to the system directory, the existing old library files will be overwritten and upgraded directly. This gives programmers a great deal of convenience. If you are careful, you will be transferred to the DLL hell trap similar to Windows. Do not do this.

[Note]

1. Specify the path to the shared library. LD_LIBRARY_PATH takes precedence over PATH environment variables.

2. LDD allows you to view the program or the path of the library on which the shared library depends.

3. interfaces for viewing shared library exposure at nm

4. ldconfig can automatically generate a soname connection file. And provides catch acceleration.

5. readelf can view the dynamic library information, such as the dependent library and its own somae.

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