Several points of note for GCC links

Library file Dependency Order

GCC is sensitive to the order of dependent libraries at link time, and dependent libraries must be placed behind, such as LIBA.A dependent LIBB.A, which must be written liba.a LIBB.A, otherwise the link will be faulted. In cases where the libraries are more complex or interdependent, or if they are not clear, the following options are used to force GCC to repeat the lookup of the Dependent libraries:

g++-O tt tt.o-xlinker "-("-lws2_32-lclsocketd-xlinker "-)"

Strong symbols and weak symbols

In a link, how does the linker handle the definition of a global symbol with the same name in multiple target files? This involves the problem of strong and weak symbols, the compiler default functions and the initialized global variables are strong symbols, the uninitialized global variables are weak symbols, both strong and weak symbols are for definition, not for symbolic references. The linker handles duplicate-defined global symbols in the following rules:

Rule 1: Strong symbols are not allowed to be defined more than once, otherwise the linker report symbol is redefined incorrectly.

Rule 2: If a symbol is strongly signed in one of the target files and is weak in other files, select the strong symbol.

Rule 3: If the weak symbol is weak in all target files, select the one that occupies the most space.

We can use GCC's __atrribute__ ((weak)) to define any strong symbol as a weak symbol, such as:

__ATRRIBUTE__ ((weak)) weak = 1;

If the definition of a symbol is not found in the link, the linker will report a symbol undefined error, which is called a strong reference. There is also a weak reference to it, and if the symbol for the weak reference is undefined, the linker does not error the reference. We can use the __attribute__ ((weakref)) keyword in gcc to declare a reference to an external function as a weak reference, such as:

__attribute__ ((weakref)) void foo ();

int main ()

{

if (foo) foo ();

}

This weak and weak references are useful for libraries, such as weak symbols defined in a library that can be overridden by strong symbols that are positioned by the user, so that the program uses a custom version of the library function, or a program can define a reference to some extended function modules as weak references, and if we remove some of the function modules, the program can also link , it just lacks the corresponding function, which makes the program function easier to crop and combine.

Global Symbolic intervention

In a dynamic link, when the linker loads the individual shared objects and merges their symbols into the global symbol table according to the dependencies between the modules, what happens if two different modules define the same symbol? This problem involves a shared object global object intervention, where a global object inside a shared object is overwritten with the global symbol with the same name as another shared object. The rules for processing dynamic linker under Linux are as follows: When a symbol needs to be added to the global symbol table, if the same symbol name already exists, then the added symbol is ignored.

Shared library version

Linux uses the shared library version approach to solve the shared library compatibility issue, which stipulates that the file naming rules for shared libraries are as follows:

Libname.so.x.y.z

X represents the major version number, and the main version number represents a significant upgrade of the library, which is incompatible between different major version numbers.

Y represents the minor version number, and the minor version number represents an incremental upgrade of the library, which adds some new interface symbols and keeps the original symbol intact. In the case where the major version number is the same, the library with the higher version number is backwards compatible with the lower minor version number.

Z indicates the release version number, the release version number indicates some bug fixes, performance improvements, etc. of the library, does not add any new interfaces, and does not make changes to the interface. The shared library is fully compatible between the same major and minor version numbers.

Linux uses a command mechanism called So-name to record the dependencies of shared libraries. Each shared library has a corresponding so-name, which so-name the file name of the shared library with the minor version number and release version number, preserving the major version number. For example, a shared library called libfoo.so.2.6.1, then its so-name is libfoo.so.2. The system creates a soft link in the same directory as so-name for each shared library and points to it, which points to the shared library with the same major version number, minor version number, and release version number in the directory.

When compiling the output elf file, the so-name that is dependent on the shared library is saved to. Dynamic so that when the dynamic linker makes a shared library dependent file lookup, it automatically directs to the latest compatible version of the shared library based on the So-name soft links in the various shared directories in the system.

Several points of note for GCC links