C language undefined reference errors when linking

All 10 Replies

http-equiv=»Content-Type» content=»text/html;charset=UTF-8″>id=»js-replies» class=»dw-replies position-relative»>

> I was creating the derived class method definitions in a cpp file
> and couldn’t get the project to progressively compile correctly.
> At my first method definition, a default constructor,
> the compiler kept spitting out this error message:

this is perhaps the most obscure error message that gcc (actually the linker) spits out, but the reason is simple:

the compiler has to put the (one and only one) vtable for a class into some object file or the other. it puts it into the object file for the translation unit where the definition of the first non-pure-virtual out-of-line virtual member function is present. if there is no such definition, you get this rather unhelpful linker error message.

you would be able to progressively compile the code even if a non-pure virtual function is not defined, but to be able to link without errors, every such function must have a definition (at least a stub). and to prevent the non-creation of a v-table by the compiler, at least one of the non-pure virtual functions will have to be defined out-of-line.

gcc has a faq about this:

> Am I to assume that the example in the book, as regards the inline feature
> of a derived class destructor, is in error.
i think it is not a particularly good book, but in this case neither the book nor the compiler is in error.
if you define the destructor inline, and out-of-line, the error will go away. there has to be at least one out-of-line definition of a non-pure-virtual function.

note: the microsoft compiler (as well as several other compilers) does not require this; it instantiates a v-table with internal linkage in *every* translation unit in which such a header (all non-pure virtual functions are inline) is included. this violates the c++ one definition rule for v-tables, but as always, folks at redmond tend to value pragmatism highly. and they do give you to suppress the proliferation of v-tables.

Thank you very much, this has certainly cleared things up. In a way, I’m glad I came across this problem, hopefully it won’t catch me out again, when progressively compiling.

Hi … I hope this helps someone out there….

I’m using netbeans with the C++ plugin in linux. I got the vtable error, and after a long time I figured out the solution..

basically the class I was trying to use was not added into the project. The class files (.cpp, .h) were in the project folder, and i was editing the files, etc… but they just wouldn’t compile because they weren’t added into the project.

so just right click the project, select «add existing items» and choose the file and add the files to the project… now it should compile, fingers crossed

I have also seen this with GCC 4 when a virtual destructor is missing a body
eg:
virtual ~MyClass(void);
should be:
virtual ~MyClass(void){};

Also if you declare a virtual constructor but forget the ‘~’ in its definition, e.g.:
virtual ~A(); // declaration in .h file
A::A() {} // .cpp implementation missing ~ in function name

That doesn’t make sense… Removing ‘~’ makes your function a ‘Constructor’ instead of a ‘Destructor’…

The only difference between the .H version and the .CXX version is that you don’t put ‘virtual’ in the .CXX file…

This error also arises in gcc if a class is inherited from a class in non included library but added include file.

Thanks. Procrastes’s answer helped. Virtual destructor was missing a body and the error was gone when I fixed it.

Dont put virtual if you dont need.

Had the same problem.
Solved by removing the macro definition for LIB_HAS_DLL.
When building an application for cross-compiling, people usually include a MACRO BLOCK similar to the one show below and use function linkage such as

LIB_FUN void myfunc();

by defining LIB_HAS_DLL this becomes __declspec(dllimport) void myfunc();
adding LIB_BUILD_DLL it becomes __declspec(dllexport) void myfunc();

removing -DLIB_HAS_DLL from the cmdline causes the function to be auto-import and mingw resolves the vtable.
/* DEFINITION for DLL Linkage */
#ifdef LIB_HAS_DLL
# ifdef LIB_BUILD_DLL
# if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__)
# define LIB_FUN __declspec(dllexport)
# else
# define LIB_FUN
# endif
# else
# if defined(_MSC_VER) || defined(__BORLANDC__) || defined(__MINGW32__)
# define LIB_FUN __declspec(dllimport)
# else
# define LIB_FUN
# endif
# endif
#else
# define LIB_FUN
#endif

Be a part of the DaniWeb community

We’re a friendly, industry-focused community of
1.19 million developers, IT pros, digital marketers,
and technology enthusiasts learning and sharing knowledge.