Node:Still unresolved, Next:, Previous:Libraries order, Up:Compiling

8.11 Some functions in C++ programs still not found

Q: I put all the libraries in the above order, but the linker still can't find some C++ functions from complex.h and iostream.h.

Q: I can't compile a program which uses the String class: the linker complains about undefined functions!

Q: I get many undefined references to symbols like __eh_pc, terminate, and __throw....

A: Some C++ functions are declared inline and defined on header files. (One example of this is the string constructor of the GNU String class.) However, GCC won't inline them unless you compile with optimizations enabled, so it tries to find the compiled version of the functions in the library. Workaround: compile with -O2.

Another cause of missing external symbols might be that your versions of libgcc.a and the compiler aren't in sync. These cases usually produce undefined references to symbols such as __throw and __eh_pc. You should only use libgcc.a from the same distribution where you got the compiler binaries. The reason for these problems is that the setup for supporting C++ exceptions is subtly different in each version of the compiler.

For C++ programs, be sure to compile all of your object files and libraries with the same version of the compiler. If you cannot recompile some of the old C++ object files or libraries, try using the -fno-exceptions -fno-rtti switches to GCC, it helps sometimes. However, note that -fno-rtti cannot be used with GCC version 2.95 and later: programs that use exceptions will crash if compiled with this option.

If you call C functions from a C++ program, you need to make sure the prototype of the C function is declared with the extern "C" qualifier. DJGPP header files take care about this, but headers you get with third-party libraries, or write yourself, might not. Failure to use extern "C" will cause the linker to look for a C++ function instead of a C function, which will fail because names of C++ functions are mangled by the compiler (to include the types of their arguments, since there can be many functions with the same name but different argument types).

Yet another possible cause for the linker to complain about undefined references is that you link files compiled using RSXNTDJ headers, or link RSXNTDJ-compiled object files with DJGPP libraries, or vice versa. DJGPP and RSXNTDJ are really incompatible as far as header files and libraries are concerned, so you cannot mix them. Add -v to the gcc command line and watch the order of searching the include directories and libraries printed by GCC: if you are compiling/linking a DJGPP program, but the RSXNTDJ directories appear first in the search order, you should change the order of the directories in the C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and LIBRARY_PATH environment variables. Similarly, if you are compiling an RSXNTDJ program, but the DJGPP's include and lib subdirectories appear first in the list printed by gcc -v, you need to put the RSXNTDJ directories first in the environment variables mentioned above.