Summary of the connector LD link sequence under Linux

Originally LD for link a series of library order is very sensitive, otherwise will report undefined referenced function symbol error, meaning is not found function definition. In fact, 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 and must be written like this. Otherwise it would be wrong.

This seems to be a legacy of history. Plainly, if you determine that a library is not important, put it to the end, that is, the loading order of the library is in order, from left to right, the highest priority, which is the ancient times the machine is too broken, the internal and hard disk including the CPU is extremely rare. So you need to deal with what needs to be done in advance, and if necessary, load it up and don't load it. This can explain the above error, the compiler loaded into the Socketcomm, found that there is a dependency on the library, and then look back, the wood has, so it is wrong.

That is to say, be relied on as far as possible back, so that everyone can share.

The other problem is that if you have multiple libraries with the same function name or class name, what happens to the struct name?

You can use commands such as NM and readelf, LDD, and so on to view your library's dependencies and symbol tables, as well as exported function symbols. This allows you to verify the different compilation results that are caused by the order above.

The test library is divided into dynamic, dynamic, static, static, static and dynamic three kinds of situations.

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

gcc-l./main.c-la-lb

Compile error, in multiple definition of ' XXX '. The function is defined repeatedly.

Second case: Dynamic library

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

GCC main.c./libb.so./liba.so

GCC main.c./liba.so./libb.so

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

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

The third case: dynamic, but is dynamically loaded, not above the static load.

GCC main.c-ldl./liba.so./libb.so

GCC main.c-ldl./libb.so./liba.so

No link option is the same as in the second case. When the L option is added, specify which to load on which.

Libb for static link!, Liba for dynamic loading.

gcc-l./main.c-ldl–lb

The library name of the dynamic library is displayed in the load-in-build option

gcc-l./main.c-ldl-lb./liba.so

gcc-l./MAIN.C-LDL./liba.so-lb

In the case of static and dynamic, the dynamic library name display is not added to the compilation option, the output is normal, if added to the static library-based and link order Independent.

References

http://fpcfjf.blog.163.com/blog/static/55469793201311260504516/

Summary of the connector LD link sequence under Linux