Solve Linux dynamic library version compatibility problem __linux

"Dynamic library version compatible", many people in the minds of the first jump is "Dll Hell." Ah, it's been a pain in the neck. Today, this problem has been solved well.

Before further discussion, consider a question: why is there no "Dllhell" under Linux?
The answer to this question is very easy, because there is no DLL at all under--linux.

Haha, of course, this is just a joke, then expand this topic, many have dynamic library system will face this problem, but their respective solutions are different.

Dll hell refers to new versions of dynamic libraries on Windows that overwrite older versions, but are not compatible with older versions. Often occurs after the program upgrade, dynamic Library update, the original program can not run up, or install new software, but the existing software can not run up.

I. Linux solutions-naming conventions
DLL on Linux, called Sharedlibrary. Linux systems face the same problems as Windows, and how to control multiple versions of a dynamic library. To solve this problem, Linux has introduced a set of naming mechanisms to address this problem, which can be avoided if this mechanism is adhered to. But it's a pact, not a compulsion. However, it is recommended that you adhere to this Convention, otherwise there will also be a Linux version of the DLL Hell problem.

Real Name
The first is the file name of the shared library itself: the name of the shared library must be as libname.so.x.y.z
Prefix "Lib" is the first, and the middle is the name and suffix of the library ". So" and the last three digits are the version number. X is the major version (Major version number), Y is the minor (Minor version number), and Z is the release version number.

Major version number (incompatible): significant upgrades, libraries between different major versions of the library are incompatible. Therefore, if you want to ensure backward compatibility, you cannot delete the old dynamic library version.

Minor version number (backward compatible): Incremental upgrade, add some new interfaces but keep the original interface. A library with a high minor version number that is backward compatible with a low minor version number.

Release version numbers (compatible): Some libraries, such as bug modifications, performance improvements, and so on, do not add new interfaces or change interfaces. The major version number is the same as this version number, and is fully compatible between different release versions.

So-name
Strictly complying with the above rules, you can avoid the issue of dynamic libraries because of version conflicts, but readers may have questions about how the dynamic linker knows which libraries the program relies on and how to choose different versions of the library when the program loads or runs.
Solaris and Linux Use the So-name (shortfor shared object name) naming mechanism to record the dependencies of shared libraries. Each shared library has a corresponding "So-name" (Shared library file name removes the minor version number and the release version number). For example, a shared library named libtest.so.3.8.2, then its so-name is libtest.so.3.


In a Linux system, the system creates a soft connection (Symbol link) that is identical to so-name and points to it for each shared library's directory. This soft connection points to a shared library with the same major version number, minor version number, and release version number in the directory. That is to say, for example, there are two shared library versions in the directory:/lib/libtest.so.3.8.2 and/lib/libtest.so.3.7.5, and soft connections/lib/libtest.so.3 point to/lib/libtest.so.3.8.2.

The purpose of establishing a soft connection with so-name is to make all modules that depend on a shared library use the so-name of the shared library when compiling, linking, and running, without the need for a detailed version number. When compiling a production elf file, if file a relies on file B, then the ". Dynamic" section of the link file in a has a dt_need type of field, and the value of the field is the so-name of B. This way, when the dynamic linker makes a shared library dependency file lookup, it is automatically directed to the latest compatible version of the shared library based on the So-name soft connections in various shared library directories in the system.

★readelf-d sharelibrary can view So-name
★linux provides a tool--ldconfig to run the tool when a shared library is installed or updated in the system, traversing all of the default shared library directories, such as/lib,/usr/lib, and then updating all the soft links to the latest shared library.

Link Name

When we use a shared library in the compiler, such as using GCC's "-l" parameters to link shared library libtxxx.so.3.8.1, you simply specify-l XXX on the compiler command line, omitting the prefix and version information. The compiler finds the latest version of the XXX library, based on the current environment, in the relevant path in the system (often specified by the-l parameter). This xxx is the "link name" of the shared library. Different types of libraries may have the same link name, for example, the C language runtime has a static version (LIBC.A) also dynamic version (LIBC.SO.X.Y.Z) of the difference, if the link to use the parameter "-LC", then the connector will be based on the output file (dynamic/static) to select the appropriate version of the library. eg. When LD uses the "-static" parameter, "-LC" looks for LIBC.A, and if you use "-bdynamic" (the default), the latest version of libc.so.x.y.z is found.

You can see in more detail
Http://www.linuxidc.com/Linux/2012-04/59071.htm


. NET solution--manifest File
. NET Framework, there are two types of an assembly (Assembly): The application assembly (. exe) and the Library assembly (DLL dynamic link library). An assembly consists of one or more files, so a manifest file (manifest file) is required to describe the assembly. The manifest file describes the assembly's name, version number, and various resources for the Assembly, as well as the resources that the Assembly relies on to run, including DLLs and other resource files. Manifest is an XML file. Each DLL has its own manifest. For an application, the Manifest file can be in the same directory as the executable file, or it can be embedded as a resource within the executable file (Embed Manifest).

XP version of Windows before executing the executable file is not considered manifest files. It will go directly to the System32 directory to find the DLL for the executable lock dependency. In this case, the manifest is superfluous. After XP, the operating system reads the assembly's manifest file first, obtains the list of DLLs that the executable needs to call, and then looks for the DLL call based on the DLL's manifest file.


Solution--com Components for Windows
The use of standard COM components, there are many benefits: interface-oriented and object programming language independence, the use of binary standards, you can achieve a cross-language version of the upgrade convenience, add a new interface, component upgrade after the old client program without recompiling location transparent, client programs do not care about the location of components reuse convenience Rapid reuse of existing components through containment and aggregation we can see that the standard COM components are very powerful, but many times we don't need all the features of a standard COM component, such as we don't want to introduce the registry or want to introduce the COM runtime, we want our program to be completely "green". Then we will use the "COM idea Architecture" to develop non-standard COM components.


Transferred from http://blog.sina.com.cn/s/blog_5cf54f0e0101cpct.html