Linux gcc link rules:
When compiling source code, the search order when linking is:
(1) The path specified by -L, search from left to right
(2) The path specified by the environment variable LIBRARY_PATH, use ":" to separate from left Go to the right and search
(3) /etc/ld.so.conf in the specified path order
(4) /lib and /usr/lib (/lib64 and /usr/lib64 under 64-bit)
Search sequence for dynamic library calls:
(1) The path specified by the -rpath parameter of ld, which is hard-coded in the code
(2) The path specified by the ld script
(3) The path specified by LD_LIBRARY_PATH
(4) /etc/ld. The paths specified by so.conf
(5)/lib and /usr/lib (/lib64 and /usr/lib64 under 64-bit)
Generally, when linking, we use -L to specify the search path, and when calling the dynamic link library, we use LD_LIBRARY_PATH to specify the link path.
Another issue to note is that as long as the first one is found, it will be returned, and subsequent ones will not be searched again.
For example -L./A -L./B -lx There is libx.a in A and libx.a and libx.so in B. At this time, libx.a in ./A will be used instead of dynamic library priority. principle, because ./A is found first, and no dynamic library with the same name exists.
For dynamic link libraries, the actual symbol positioning is performed during runtime. When compiling .so, if the libraries it requires are not compiled with it, for example, libx.so needs to use uldict, but forget to compile libx If -luldict is added to .so, no error will be reported when compiling libx.so, because libx.so is considered a library at this time, and it is legal to have some symbols in it that do not know the specific implementation, and can be used in Specify it at runtime or when compiling another binary program.
If you use g++ -Lpath -lx to compile, the linker will find that the required symbol table of uldict cannot be found and report an error. However, if the program is loaded using dlopen, since it is running time, the program will be in this The place will run directly and an error will be reported. Another situation is that an external interface has been declared and defined in the dynamic library, but it has been forgotten to implement it. At this time, a similar error will also occur.
If such an error is reported during runtime, you should pay attention to whether it is caused by some libraries not being linked in or some interfaces not being implemented.
With the above foundation, it is not difficult to see that the reasons for undefined reference and undefined symbol errors are:
(1) The corresponding library (.o/.a/.so) is not specified. Using an entity defined in the library without specifying the library (-lXXX) or not specifying the library path (-LYYY) will cause this error.
(2) The order of the connection library parameters is wrong. By default, the requirement for -l to use libraries is that the more basic the library, the more basic it must be written at the end, whether it is static or dynamic.
(3) gcc/ld version mismatch. Gcc/ld version compatibility issues, due to the compatibility issues between gcc2 and gcc3 major versions (in fact, gcc3.2 to 3.4 also have such problems to a certain extent) when using a lower version machine on a higher version machine, it will Leading to such errors, this problem is more common in 32-bit environments. In addition, 64-bit libraries are accidentally used in 32-bit environments, or conversely, 32-bit libraries are used in 64-bit environments.
(4) C/C++ interdependence and linkage. The mixed use of gcc and g++ compilation results needs to ensure that extern "C" can be used on both sides of the interface. In our 64-bit environment, gcc needs to be linked to the g++ library with -lstdc++. For details, see the previous description of mixed compilation.
(5) Error reported during runtime. This problem is basically due to the program using the dlopen method to load .so, but .so does not link all required libraries. For details, please refer to the above description of the mixed use of static libraries and dynamic libraries.