Node:Still unresolved,
Next:djgpp_first_ctor,
Previous:Libraries order,
Up:Compiling
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.