Chen Yunwen

When compiling programs under Linux, we often encounter “undefined reference to XXX” error,

Here is a summary of some possible reasons and solutions for those in need:

Speaking of undefined reference error, let’s first mention the link rules of Linux GCC

The search order of links is as follows:

– L to find the path specified by the environment variable library from left to right_ Path, use the ‘:’ partition to find / etc from left to right/ ld.so.conf The specified path order is / lib and / usr / lib (64 bit is / lib64 and / usr / lib64)

Search order of dynamic library calls:

The path specified by the – rpath parameter of

LD is the path specified by the LD script that is written dead in the code_ LIBRARY_ Path / etc/ ld.so.conf The specified paths / lib and / usr / lib (64 bit is / lib64 and / usr / lib64)

In general, we use the – L method to specify the search path when linking, and use LD when calling dynamic link library_ LIBRARY_ Path to specify the link path

Another problem to note is that as long as the first one is found, it will be returned, and the later ones will not be found. For example, – L. / a – L. / B – LX has libx in a, libx. A and libx. A in B libx.so In this case, libx. A in. / a will be used instead of following the principle of dynamic library priority, because. / A is found first and there is no dynamic inventory with the same name in

For dynamic link library, the actual symbol positioning is carried out at run time. When compiling. So, if the library it needs is not associated with it, such as libx.so You need to use uldict, But forget to compile libx.so Add – luldit when compiling libx.so I won’t make a mistake when I’m here, because at this time libx.so It is considered as a library, in which there are some symbols that do not know the specific implementation, which are legal and can be specified at runtime or when compiling other binary programs

If G + + – lpath – LX is used The linker will find that the required uldict symbol table can not be found and report an error. However, if the program is loaded in dlopen mode, the program will run directly in this place and report an error because it is in runtime. Another case is that an external interface has been declared and defined in the dynamic library, but it has forgotten to implement it. At this time, the Similar mistakes can occur

If such an error is reported in the runtime, we should pay attention to whether it is due to the fact that some libraries are not linked or some interfaces are not implemented

With the above foundation, it is not difficult to see that the reasons for the undefined reference error are as follows:

no corresponding library (. O /. A /. So) uses the entity defined in the library, but no library (- LXXX) or library path (- lyyy) is specified, which will lead to this error. The order of connecting library parameters is not right. By default, the more basic the library is, the more it should be written later, Whether it is static or dynamic, the version of GCC / LD does not match the compatibility of the version of GCC / LD. Due to the compatibility problems of the large versions of GCC 2 to GCC 3 (in fact, there are some problems in GCC 3.2 to 3.4), when using the low version of the machine on the high version machine, such errors will be caused. This problem is more common in the 32-bit environment, In addition, the 64 bit library is used carelessly in the 32-bit environment, or vice versa. The C / C + + interdependence and the mixed use of linking GCC and G + + compilation results need to ensure that both sides of extern “C” can use the interface. In our 64 bit environment, the GCC linking G + + library also needs to add – lstdc + +, For details, please refer to the description of hybrid compilation in the previous article. The problem of runtime error is basically due to the program using dlopen mode to load. So, but. So does not link all the required libraries. Please refer to the description of hybrid use of static library and dynamic library in the above section