8.1 Versions of shared libraries
Updates to shared libraries can be divided into two categories:
Compatible updates. All updates are only added to the original shared library, and all existing interfaces remain intact.
Incompatible updates, shared library updates change the original interface, programs that use the original interface of the shared library may not run or run abnormally
The interface discussed here is the binary interface, ABI
There are 4 main behaviors that cause the C-language shared library ABI to change:
1) The behavior of the exported function has changed
2) The export function is deleted
3) The structure of the exported data is changed
4) The interface of the exported function changes, such as the function return value, the parameter has been changed
Shared library version naming:
Linux has a set of rules for each shared library in the chain naming system, libname.so.x.y.z
"X" represents the major version number, "Y" indicates the minor version number, "Z" indicates the release version number
So-name
Both Solaris and Linux systems use a naming mechanism called So-name to record the dependencies of a shared library, and each shared library has a corresponding "So-name", which is the so-name of the shared library minus the minor and release version numbers, leaving only the name of the major version number.
On a Linux system, a soft link to a shared library is created for each shared library in the directory where it is located, "So-name"
The purpose of establishing a soft connection with the name "So-name" is to make all modules that depend on a shared library, compile, link, and run with the so-name of the shared library, without using a detailed version number
Linux provides a tool called "Ldconfig", which creates or updates a soft connection to this shared library when a shared library is installed or updated in the system
8.2 Symbol Version
Symbol versions in Linux
The symbolic version mechanism of shared libraries under Linux systems is not widely used, and is mainly used in more than 20 shared libraries provided in the GLIBC software package.
These shared libraries are more effective at using the symbolic version mechanism to represent the symbol's version of the evolutionary machine using the range mechanism to mask some symbols that you do not want to expose to shared library users
The shared library symbol version mechanism under Linux is not widely used, and the main use of the shared library symbol version mechanism is the more than 20 shared libraries provided in the GLIBC software package.
GCC allows the use of a compilation macro called ". Symver" To specify the version of the symbol, which can be used in gas compilation or in the form of an embedded assembler instruction in the GCC C + + source code.
ASM (". Symver add, [email protected]_1.1")
int add (int a,int b)
{
return a + B;
}
GCC allows multiple versions of the same symbol to exist in a shared library, i.e., a mechanism for symbolic overloading at the link level, as follows:
ASM (". Symver old_printf, [email protected]_1.1")
ASM (". Symver new_printf, [email protected]_1.2")
int old_printf () {...}
int new_printf () {...}
Under Linux, when we use LD to link a shared library, we can use the "--version-script" parameter, if you use GCC, you can use "-xlinker" parameter Plus "--version-script", equivalent to "-- Version-script "Pass
to the LD linker
Gcc-shared-fpic lib.c-xlinker--version-script Lib.ver-o lib.so
vers_1.2{
Global
Foo
Local
*;
}
8.3 system paths for shared libraries
The Linux system complies with the FHS standard, and FHS rules that there are 3 locations in a system where shared libraries are stored
/lib,/usr/lib,/usr/local/lib
The shared object since the program is loaded and initialized by the dynamic connector
Dynamic Connector for the module to find a certain rule, if the dt_need inside the absolute path is saved, then the dynamic linker to follow this path to find, if the dt_need is stored in a relative path, then the dynamic Connector will be/lib
/usr/lib and find shared libraries in the directory specified by the/etc/ld.so.conf configuration file
Linux system has a program called Ldconfig, this program in addition to the shared directory under the shared library to create, delete or update the corresponding So-name, will also collect these so-name, centralized storage to/etc/ Ld.so.cache file, create a so-name cache
If the dynamic connector does not find the required shared library in/etc/ld.so.cache, it will also traverse both directories/lib and/usr/lib
8.4 Environment Variables
Ld_library_path
The Linux system provides a LD_LIBRARY_PATH environment variable that can be used to change the shared library lookup path, which can temporarily change the shared library lookup path for an application without affecting other programs in the system
In a Linux system, Ld_library_path is an environment variable that consists of several paths, separated by colons between each path
Dynamic connectors mount or find shared objects in the following order:
Path specified by the environment variable Ld_library_path
Path specified by path cache file/etc/ld.so.cache
Default shared library directory,/usr/lib first, then/lib
Ld_preload
There is an environment variable in the system called Ld_preload, which we can specify a pre-loaded shared library or a target file
The shared library or target file specified inside the Ld_library_path priority ld_preload is loaded
Because of the existence of the mechanism of global sign intervention, the ld_preload in the shared library or target file will overwrite the global symbol that is loaded later, which makes it convenient for us to sit down one or several functions in the standard C library without affecting the other functions. Useful for testing or debugging a program
When there is a file in the system configuration file/etc/ld.so.preload It works the same as Ld_preload. This file is recorded in the shared library or target file effect ld_preload specified in the same
Ld_debug
This variable can open the Dynamic linker debugging function, when we set up this variable, the dynamic linker will print a variety of useful information at run time, for us to develop and debug the shared library is a great help
Ld_debug can set a number of values:
The files dynamic linker prints out the entire load process, which shared libraries the explicit program relies on and what steps are loaded and initialized, and the address at which the shared library is loaded
Bindings displaying the symbolic binding process for dynamic linking
Libs displaying the lookup process for shared libraries
Versions version dependencies for display symbols
Reloc Show Relocation Process
Symbols show symbol table lookup process
Statics displaying various statistics during dynamic linking
All displays all of the above information
Help displays helpful information for the various optional values above
8.5 creation of shared libraries
The process of creating a shared library is consistent with the process of creating a common shared object, most crucially with the two parameters of GCC, that is, "-shared" and "-fpic" "-shared" indicate that the result of the output is a shared library type, and that "-fpic" means using address-independent code to produce the output file. Another parameter is the "-W1" parameter, which can pass the specified arguments to the linker, such as: when we use "-w1,-soname,-my_soname", gcc passes "-soname my_soname" to the linker
The parameter "-rpath" option for LD specifies that the linker generates a shared library lookup path for the target program, for example, we use the following command line to generate an executable file
Ld-rpath/home/mylib-o Programe.out Programe.o-lsomelib
The LD linker provides a "-export-dynamic" parameter that indicates that the linker will place all global symbols everywhere in the dynamic library symbol table when producing the executable file.
Clear symbol Information:
With the Strip tool, you can clear all symbols and debug information for a shared library or executable file
Strip libfoo.so
Installation of shared libraries
After creating the shared library we have to install them in the system so that the various programs can share it, the simplest way is to copy the shared library to a standard shared library directory, such as:/lib,/usr/lib, etc., and then run Ldconfig to
Shared library constructs and destructors
GCC provides a constructor for shared libraries, as long as the function declaration is prefixed with "__arttribute__ (Construcor)", which specifies that the function is a constructor for a shared library, and functions that have this property are executed when the shared library is loaded. Which is executed before the main function of the program,
corresponding to the shared library is the destructor, we can use the function declaration with the "__attribute__ (destructor)" property, this function will be executed after the main () function is completed
The format of the declaration constructor and destructor is as follows:
void __attribute__ ((constructor)) init_function (void);
void __attribute__ ((destructor)) fini_function ();
GCC provides us with a parameter called priority, and we can specify the priority of a constructor or destructor:
void __attribute__ ((constructor (5))) init_funciton1 (void);
void __attribute__ (Constructor ())) init_function2 (void);
Organization of Linux shared libraries--learning Notes
