Shulou(Shulou.com)06/01 Report--

This article focuses on "how to understand the ld link order of connectors under the Linux system". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Next let the editor to take you to learn "how to understand the ld link order of connectors under Linux system"!

It turns out that ld is very sensitive to the order in which a series of libraries are linked, otherwise it will report a function symbol error in undefined referenced, which means that the function definition has not been found. Actually, the library can be opened correctly. If the library libA.a depends on the library libB.a, then the parameters of the connector should be ln-lA-lB, which must be written like this. Or you'll make a mistake.

This seems to be a legacy of history. To put it bluntly, if you are sure that a library is not important, put it at the end, that is to say, the loading order of the library is in order, from left to right, with the highest priority, which is also the reason why machines in ancient times are too broken, internal and hard drives, including CPU, are extremely rare and precious. So you have to figure out in advance what you need and what you don't need, once you need it, load it, and don't load it if you don't need it. This can explain the above error, the compiler loaded into socketcomm, found that there are dependent libraries, and then look back, there is nothing, so it is wrong.

In other words, the dependent ones should be put in the back as far as possible so that everyone can share them.

This leads to another question: what happens to the structure name if there are multiple libraries using the same function name or class name?

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

The library of the test is divided into three cases: dynamic, dynamic, static and static.

The first case: quiescent libraries all contain the same name function

The code is as follows:

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

Compiler error, in multiple definition of `XXX'. Define the function repeatedly.

The second case: moving library

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

The code is as follows:

Gcc main.c. / libB.so. / libA.so

The code is as follows:

Gcc main.c. / libA.so. / libB.so

Such links are implicit links, or load-time links, while the previous static libraries are compile-time links.

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

The third case: dynamic, but dynamic loading, rather than the static loading above.

The code is as follows:

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

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. With the L option added, specify which to load.

LibB is a static link, libA is a dynamic load.

The code is as follows:

Gcc-L. / main.c-ldl-lB

In the add-load compilation option displayed by the library name of the dynamic library

The code is as follows:

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

The code is as follows:

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

At this point, I believe you have a deeper understanding of "how to understand the ld link order of connectors under the Linux system". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.