"Linux Notes" detail the naming conventions and usage methods of shared libraries under Linux system

1. The benefits of the Shared library
A shared library, also known as a dynamic library or so file, can be called when the executable file is started or when the process runs. There are many benefits to using shared libraries, such as (including but not limited to the scenarios mentioned below):
1) reduces the size of modules that rely on shared libraries because they do not have to statically compile the implementation code of the functionality provided by the shared library into their own module code.
2) Multiple processes running on the same machine share the same dynamic library in memory, and the memory layout used by the operating system can greatly save machine memory resources.
3) If many modules rely on the same underlying library provided in a shared library, the underlying library upgrade can only be done by upgrading the so file, without recompiling the application module, and if the underlying library is integrated in a statically compiled form inside the upper module, each module that relies on the library needs to be recompiled.
4) Some applications that do not support the new version so library can continue to use the old version, even if some of the so libraries do not meet the latter compatibility and can be upgraded.
5) The application can use the so library to cover some libraries, and it can overwrite some of the functions in the library (that is, still use a library, but some functions in the library are overwritten with functions of the same name in the so library).
Because the shared library has its own unique scenario application advantage, the underlying library of the *nix operating system is basically provided as a shared library (*.so), but the underlying library of the Windows operating system is also provided as a shared library (*.dll).

2. Naming and deployment conventions for the Shared library
To facilitate the management of dependencies, when you create or deploy a shared library, you must follow the rules for uniform conventions, including the naming conventions for dynamic libraries and how they are deployed.
2.1 Shared Library Naming conventions
1) Each dynamic library has a "lib" prefix and ". so.x" as the end of the calledSonamea specific name, where x is the main version number, and the Soname naming format is typically libxxx.so.x. For example, the soname of the Zlib shared library on my Linux system machine is libz.so.1
2) Each dynamic library also has a file name that contains the real library code, often referred to as the realnameof the library, which increases the version number (minor numbers) and the release number (soname), compared to the The naming format is typicallylibxxx.so.x.y.z, where the x in the so suffix is the main version number, Y is the secondary version number, and Z is the release version number. For example, the realname of the Zlib shared library on my Linux system machine is libz.so.1.2.8
3) In addition, when linking or starting an application module that relies on a shared library, the linker (linker) or loader only recognize the shared library name without any version number,This documentThe name of the library to be used for Linker/loader "linker name". In other words, when a module that relies on the zlib library is linked or started, linker or loader will only find a shared library named libz.so, which will cause an error if it is not found.
The above mentioned Realname/soname/linker name 3 naming conventions are the key to the Linux system Management shared library,In specific terms:
1) When a library developer creates a shared library, the library is typically named Realname
2) When a version of the shared library is installed, the installation script usually downloads the corresponding version of the library file named Realname, and then calls the Ldconfig tool built into the Linux system to generate a soft chain called Soname for the library file named Realname and put the soft chain relationships are updated to/etc/ld.so.cache
3) The installation script creates a library name without a version number (that is, the linker name of the shared library), which is a symbolic link to the library soname
4) When updating the new shared library, the installation script repeats the 2nd step above
Of course, we can completely manually complete the two soft-link settings in the above steps. Also take the Zlib shared library on my Linux system machine as an example, it has a library name called LIBZ.SO for linker to find at link time, and the library name is a pointer to Libz.so.1soft chain, while Libz.so.1 is a soft chain pointing to libz.so.1.2.8.
The two-tier soft-chain deployment Convention provides the convenience of coexistence or shared library upgrades between different versions of a shared library under the same system: the upper module that relies on a shared library does not care about the latest version of the shared library under the current system, As long as the latest version has been successfully installed and Soname points to the latest version of Realname, the upper-level module will automatically load the latest version of the shared library by loader the next time it starts.
A few additional notes on the open source software version number for UNIX-like platforms:
1) If the new version of the shared library is released and the external interface is not compatible with the previous versions of the interface, the major version number needs to be added 1
2) If the published version of the shared library only modifies the internal implementation logic (such as Bug fix), its external interface is compatible with the old version, the major version number is unchanged, the minor version number plus 1
2.2 Shared Library Deployment path
Open source software deployment paths typically followGNU Default ConventionsorFHS Standard(Filesystem Hierarchy Standard). The specific deployment path depends on the purpose of the library, for most of the shared library users, in fact, do not have to know too much detail, here no longer repeat. If you are interested, you can check the relevant information.

3. How the upper module uses shared libraries
3.1 Shared library default lookup path
in Linux systems, when the ELF format 2 executable file is started, the operating system built-in program loader (such as/lib/ Ld-linux.so.2) automatically finds and loads the shared libraries that the module relies on (if the path to the shared library that you specified depends on is not displayed at compile time, the loader lookup order can refer to the Description section of this document when the module starts). By default, loader willlooking for a candidate set in/etc/ld.so.conf, if the lookup fails, an error similar to "Cannot open shared object File:no such file or directory" is reported.
Therefore, in the case of root access, we will add the shared library path we rely on to/etc/ld.so.conf.
3.2 How to override some functions of a library
If we want to overwrite a function with the same name in a shared library with some functions (such as a more efficient memory allocation function instead of the malloc function that comes with the system), we can configure the target file path (XXXPATH/XXX.O) containing the new version of the functionto/etc/ld.so.preload, the functions contained in these preload XXX.O files will overwrite the functions of the same name in other libraries when compiling the upper-level modules. Of course, you can also configure the compiled shared library path here, depending on the module runtime,The functions in the shared library configured here overwrite the functions of the operating system base library with the same name.
It is particularly necessary to note that:modifying the configuration in the Ld.so.preload file may affect all users on the machine, so the configuration process requires root privileges. Of course, even the root user must be cautious when modifying these configuration files that may affect the global profile.
3.3 How to make loader efficient find shared libraries
obviously, when the upper module starts, it is not efficient to traverse the/etc/ld.so.conf or/etc/ld.so.preload to find dependent shared libraries, so the Linux system introduces the cache mechanism. We can use the Ldconfig command toshared libraries configured in/etc/ld.so.conf create the cache item in/etc/ld.so.cache (another feature of the Ldconfig command is to create a soname soft chain for Realname, which is mentioned in section 2.1 of this article). Shares listed in the Ld.so.cacheThe library is loader to be efficiently found.
3.4 Typical environment variables that affect shared library lookup paths
1) ld_library_path
in a Linux system, you can use Ld_library_path to specify multiple shared library paths separated by colons. When a module that relies on these libraries is linked or started, the path specified by Ld_library_path is either linker or loader first (takes precedence over the/lib or/usr/lib of these default search paths or the search path specified by/etc/ld.so.conf).
Note 1:the method of specifying shared library search paths with Ld_library_path is very convenient for development/debugging modules, butIn most cases, you should not export Ld_library_path to a Global environment variable under an account in ~/.bash_profile.. Because once Ld_library_path becomes the default global environment variable for an account, it can be dependent on many modules, and once many modules have relied on the path specified by the variable to find the shared library, if the variable iswhen someone changes or deletes, the modules that depend on the global environment variable will not start properly!
of course, if you temporarily export Ld_library_path content in the current shell terminal or script every time you start a module that relies on shared libraries, even through Ld_library_ path Specifies a search path without serious consequences (because this non-global variable setting is only valid in the current shell and its subshell, and does not affect other modules), but it is not very elegant.
The elegant solution is:before compiling the module, specify the path of the loader search shared library at startup by-rpath option for the LD in makefile. Thus, when the module is deployed, loader searches for shared libraries under that path as long as the shared library path is consistent with the-rpath path specified in makefile.
Another workaround:use the following command to start an application that relies on a shared library

/lib/ld-linux.so.2--library-path So_path executable [arg1, arg2, ...]

Where So_path is the path to the shared library, executable is the application to start, Arg1-argn is the program's input parameters
NOTE 2:in some unix-like systems, the environment variable name that implements the same functionality may not be ld_library_path (such as the environment variable named Shlib_path defined in the HP-UX system), which you need to be aware of when you use it.
2) ld_preload
This environment variable is used to specify the path of the. o file or shared library, linker the upper module, or loader load the boot information of the upper module, in the. o file specified by ld_preload or the shared library's function overrides the name of the other library to which it depends .function.
For information on how to specify a custom library to overwrite other libraries with the same name function when the module starts, refer to the example here.
3) ld_debug
by setting this environment variable, you can output verbose information for the loader process when the module process starts, such as loader find out which shared libraries the module depends on and which shared libraries are loaded.
This debug log can help us locate some shared library-related exception issues.
4) Other environment variables
In addition to the above 3 commonly used environment variables, there are also some environment variables that affect the behavior of shared libraries, but these variables are lower level, to the bottom of the library developers more significance, for the upper level of the library callers, the contact is not a lot of opportunities. Interested can see these variable names in the shell terminal through the man ld.so, here do not repeat.

Resources
1. The Linux Document project:shared Libraries
2. Why Ld_library_path are bad
3. A Simple Ld_preload Tutorial
4. Linux Programmer ' s Manual:ld.so

======================= EOF ====================

"Linux Notes" detail the naming conventions and usage methods of shared libraries under Linux system