[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OT: converting C to C++ : linkng problems

Gregory Seidman wrote:
On Tue, Dec 13, 2005 at 10:14:37AM -0600, Mike McCarty wrote:
} Joris Huizer wrote:
} >That makes sence, but still - it's exactly the same code as used in C } >and the C code compiles fine (except for some added casts as C++ doesn't } >like coercing void pointers to something else) } >if I do an objdump it seems those functions that are not found have been } >mangled by C++ } } C is not C++
} C is not a subset of C++
} They are different languages
} There is a subset of C++ which resembles C very closely

Actually, C is a proper subset of C++. In fact, the C++ standard is based
on the C standard. Some changes were made to the C standard (in 1999, as I
recall) to reconcile it with C++.

} One common error is to compile C with a C compiler (or
} a C++ compiler in "C Mode") and then try to link it
} with C++ compiled with a C++ compiler. This won't work.
} } Your C routines must be compiled with a C++ compiler
} IN C++ MODE, or they must be declared as extern C {...}
} otherwise you'll get linking problems.

To properly understand why this is requires some significant knowledge of
how compilers, assemblers, and linkers interact. The high-level explanation
is that code written in any language refers to things that exist (or are
placed at runtime) at particular memory addresses. The linker is
responsible for resolving those references, and uses unique symbol names to
do so. Those symbols can be referred to from various compilation units
(i.e. .o files), but must be defined/implemented in only a single
compilation unit.

Usually those symbol names directly correspond to C function or variable
names, but since it is possible to have various methods with the same name
with different signatures (i.e. overloaded methods) or in different
contexts (e.g. classes) it is necessary for the C++ compiler to "mangle"
the symbol names to include information about their contexts and
signatures. This mangling is deterministic, so code referring to a
particular function will be compiled to refer to the mangled name for the
function. If that function is actually compiled by a C compiler, however,
it will have an unmangled symbol name and, thus, mangled references to it
will be undefined. C++ provides the extern "C" directive to indicate that
the following (or enclosed) function(s)/variable(s) should be referenced
with unmangled symbol names.

} Mike

Thanks for some background -- but this really is not the issue in my case, as I changed the Makefile to compile everything with g++ - that is, there are no C-bits mixed with C++ bits - it's still a mystery to me how C++-mangled function names end up not being found by the same C++ compiler but... I'll check for C prototypes without any parameters and the information on bison+C++ ...

Though it might be the case that output of `flex --c++ spascal.l` causes problems :-/

Thanks for all the input so far :-)


Reply to: