| www.delorie.com/djgpp/v2faq/faq060.html | search |
| www.delorie.com/djgpp/v2faq/faq060.html | search |
| Previous | Next | Up | Top |
Q: I get many undefined references to symbols like __eh_pc, terminate, and __throw...
inline and defined on header files. 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 -O.
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.
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 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.
| webmaster donations bookstore | delorie software privacy |
| Copyright ⌐ 1998 by Eli Zaretskii | Updated Sep 1998 |
You can help support this site by visiting the advertisers that sponsor it! (only once each, though)