Linux under the compiler program, often encounter "undefined reference to XXX" error,
Here is a summary of some possible causes and solutions for the needy friends:
Said undefined reference error, first mention the Linux GCC link rules:
The search order when linking is:
- Path specified by-L, looking from left to right
- The path specified by the environment variable Library_path, using the ":" Split to find from left to right
- /ETC/LD.SO.CONF the specified path order
- /lib and/usr/lib (64-bit is/lib64 and/usr/lib64)
Lookup order for Dynamic library calls:
- The-rpath parameter of the LD specifies the path, which is written dead in the code
- The path specified by the LD script
- Ld_library_path the specified path
- /ETC/LD.SO.CONF the specified path
- /lib and/usr/lib (64-bit is/lib64 and/usr/lib64)
General Link when we use the-l to specify the lookup path, call the dynamic link library when the Ld_library_path way to specify the link path.
Another concern is that as soon as the first one is found, it will be returned, and the latter will no longer be looked up. For example-L./A-L./B-LX in a libx.a B has libx.a and libx.so, this time will use in./a libx.a instead of following the principle of dynamic library precedence, because./A is found first, and there is no dynamic inventory with the same name
For dynamic-link libraries, the actual symbolic positioning is performed at run time. When compiling. So, if the library that it needs is not associated with him, for example libx.so needs to use Uldict, But forget in the compile libx.so when add-luldict words, in compiling libx.so time will not error, because this time libx.so is considered a library, it has some do not know the specific implementation of the symbol is legal, it can be specified during the run time or compile another binary program.
If you are using g++-LPATH-LX to compile, the linker will find that the required uldict symbol table can not be found to error, but if the program is loaded in Dlopen way, due to the operation period, the program in this place directly run the error. Another situation is that an external interface has been declared defined in the dynamic library, but it has been forgotten, and this time a similar error occurs.
If you report such errors at run time, be aware of the fact that some libraries are not linked in or that some interfaces are not implemented.
With the above foundation, it is not difficult to see that the reason for undefined reference error errors is:
- This error is caused by not specifying the corresponding library (. o/.a/.so) using the entity defined in the library, but not specifying the library (-LXXX) or not specifying a library path (-LYYY).
- The order of the connection library parameters is not correct by default, the requirement for-L uses the library is that the more basic the library is written behind, whether it is static or dynamic
- The GCC/LD version does not match the compatibility issue with the version of Gcc/ld, because of a problem with the compatibility of the GCC2 to gcc3 large version (in fact gcc3.2 to 3.4 also has a certain degree of this problem) when using a lower version of the machine on a high-version machine will cause such errors, This problem is more common in 32-bit environments, in addition to the 32-bit environment accidentally using 64-bit libraries or the reverse 64-bit environment using 32-bit libraries.
- Cross-C + + interdependent and linked GCC and g++ compilation results are required to ensure that the interface can be used on both sides of the extern "C", in our 64-bit environment, GCC link g++ Library also need to add-lstdc++, see the previous article for the description of mixed compilation
- Run-time error This problem is basically due to the fact that the program uses the Dlopen mode to load. So, but. So does not link all the required libraries, specifically to the previous instructions for mixing static and dynamic libraries
Linux under the compiler program, often encounter "undefined reference to XXX" error,