How to sort the connector ld link under Linux

The order of the connector ld link in Linux system is very important. If the order is not correct, it will cause the undefined referenced function to report an error. The following small series will introduce you how to arrange the connection under Linux. The order in which ld is linked.

ld original order for a series of link library is very sensitive, otherwise it will report an error function symbol undefined referenced, meaning that the function definition is not found. In fact, the library can be opened correctly. If the library libA.a depends on the library libB.a, then the connector's argument should be ln -lA -lB, which must be written like this. Otherwise it will be wrong.

This seems to be a legacy of history. To put it bluntly, if you determine that a library is not important, it is put to the end, that is, the order in which the libraries are loaded is in order, from left to right, with the highest priority, which is why the machines in the ancient times were too broken. The internal and hard drives including the CPU are extremely rare and precious. So you need to get what you need in advance and don't need it. Once you need it, load it up. Don't load it if you don't need it. This can explain the above error, the compiler loaded into socketcomm, found that there is a dependency library, and then look for it, there is a flaw, so it is wrong.

In other words, the dependencies are placed as far as possible so that everyone can share them.

This leads to another problem. If there are multiple libraries, using the same function name or class name, what happens to the structure name?

You can use nm and readelf, ldd and other commands to view your library's dependencies and symbol tables and exported function symbols. This will allow you to verify the different compilation results above because of the order.

Divide the test library into dynamic and dynamic; static and static;

The first case: the static library contains the same name function

The code is as follows:

gcc -L./main.c -lA -lB

Compile error, in multiple definition of `XXX‘. Repeat the definition function.

The second case: the moving library

This depends on the order of loading, as mentioned above, starting from the left, loading as needed.

The code for the code is as follows:

gcc main.c . /libB.so . /libA.so

The code for the code is as follows:

gcc main.c . /libA.so . /libB.so

Such a link is implicitly linked, or a load-time link, while the previous static library is a compile-time connection.

That is, the order of compilation determines which library in the library is called with the same name.

The third case: moving, but dynamic loading, not the static loading above.

The code for the code is as follows:

gcc main.c -ldl . /libA.so . /libB.so

The code for the code is as follows:

gcc main.c -ldl . /libB.so . /libA.so

When there is no link option, it is the same as the second case. After adding the L option, specify which one to load.

libB is a static link! , libA is dynamically loaded.

The code of the code is as follows:

gcc -L./main.c -ldl –lB

The library name of the dynamic library is displayed in the compile option. >

The code for the code is as follows:

gcc -L./main.c -ldl -lB . /libA.so

The code for the code is as follows:

gcc -L./main.c -ldl . /libA.so -lB

When there is static and dynamic, do not add the dynamic library library name to the compile option, the output is normal, if added, the static library is mainly related to the link order.

The above is the introduction of the ld link order of the connector under Linux system. Different order will result in different compilation results. Therefore, it should be placed as far as possible after the dependency. Do you remember?