I've been searching for a while and have found a lot of threads/pages that involve the problem I have, but I am not able to find
An explanation of why this error occurs
A working solution for my specific case
The following is Scanner.h:
class BaseReader {
public:
virtual ~BaseReader();
virtual const char* read() = 0;
virtual long position() = 0;
virtual long size() = 0;
virtual void seek(long position) = 0;
};
class CharReader : public BaseReader {
public:
CharReader(const char* source);
CharReader(const char* source, long size);
~CharReader();
const char* read();
long position();
long size();
void seek(long position);
private:
char* _source;
long _position;
long _size;
};
In Scanner.cpp I simply implement one of the constructors of CharReader.
I use Code::Blocks, but compiling it by myself results in the exact same problem.
niklas#emerald:~/git/hiterator (CPP)$ g++ main.cpp hiterator/Scanner.cpp -o main
/tmp/cclNNwgl.o: In function `hiterator::CharReader::CharReader(char const*)':
Scanner.cpp:(.text+0x16): undefined reference to `vtable for hiterator::CharReader'
collect2: ld gab 1 als Ende-Status zurück
#qdii:
#include "Scanner.h"
using namespace hiterator;
#include <stdlib.h>
#include <string.h>
CharReader::CharReader(const char* source) {
_size = strlen(source);
_source = (char*) malloc(_size + 1);
memcpy(_source, source, _size + 1);
}
Your program is incorrect. All virtual functions are considered used (odr-used) and thus you need to provide the definitions for all of them. Once you fix that, the issue should go away.
The compiler is complaining that the vtable is not available. Vtable-s are an implementation detail, and thus not treated by the standard, but many compilers will generate the vtable in the translation unit that defines the first (non-inline) virtual function. In your case, whatever the criterion to generate the vtable is, you are not complying with it.
See what I wrote on the GCC wiki to explain undefined reference to vtable for X errors.
There are also loads of existing questions on SO about that linker error, I'm sure one of them has an answer that explains it, e.g. here or here
You declared, but didn’t define, the virtual destructor in BaseReader. You need to provide a definition for this in the .cpp file in order for the vtable for BaseReader to be generated. Same for CharReader.
Related
I think it's important to note that this compiles fine on Visual Studio 2012, but not in g++. It evened compiled fine at one point before I implemented RSA.cpp. I haven't touched the header files since. The error is:
cipher.o: In function `RSA_433::RSA_433()':
/home/andrew/Desktop/ciphers/RSA.h:18 undefined reference to `vtable for RSA_433'
collect2: error: ld returned 1 exit status
Here's RSA.h:
class RSA_433: public CipherInterface
{
public:
RSA_433(){}
virtual bool setKey(const unsigned char* key);
virtual unsigned char* encrypt(const unsigned char* plaintext);
virtual unsigned char* decrypt(const unsigned char* ciphertext);
protected:
RSA* RSAkey;
const char* keyFileName;
};
and RSA.cpp:
//RSA_433::RSA_433(){} removed
bool RSA_433::setKey(const unsigned char* key){//body}
unsigned char* RSA_433::encrypt(const unsigned char* plaintext){//body}
unsigned char* RSA_433::decrypt(const unsigned char* ciphertext){//body}
RSA.h also inherits from:
class CipherInterface
{
public:
CipherInterface(){}
virtual bool setKey(const unsigned char* key){ return false; }
virtual unsigned char* encrypt(const unsigned char* plaintext){ return NULL; }
virtual unsigned char* decrypt(const unsigned char* ciphertext) { return NULL; }
};
You seem to have two definitions for RSA_433::RSA_433(). One in the .h file and one in the .cpp file
Also, all the methods defined in class CipherInterface are inline. According to GCC standard,
The ISO C++ Standard specifies that all virtual methods of a class
that are not pure-virtual must be defined, but does not require any
diagnostic for violations of this rule [class.virtual]/8. Based on
this assumption, GCC will only emit the implicitly defined
constructors, the assignment operator, the destructor and the virtual
table of a class in the translation unit that defines its first such
non-inline method
That means GCC will only include vftable in the object file for the translation unit where the definition of the first non-pure, and non-inline virtual member function is present. If there is no such definition, vftable will not be included for the class.
The answer is simple: You should add and implement a virtual destructor in CipherInterface and the problem will go away.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
GCC C++ Linker errors: Undefined reference to 'vtable for XXX', Undefined reference to 'ClassName::ClassName()'
I'm doing a little project in C++ and I've come into some problems regarding virtual functions.
I have a base class with some virtual functions:
#ifndef COLLISIONSHAPE_H_
#define COLLISIONSHAPE_H_
namespace domino
{
class CollisionShape : public DominoItem
{
public:
// CONSTRUCTOR
//-------------------------------------------------
// SETTERS
//-------------------------------------------------
// GETTERS
//-------------------------------------------------
virtual void GetRadius() = 0;
virtual void GetPosition() = 0;
virtual void GetGrowth(CollisionShape* other) = 0;
virtual void GetSceneNode();
// OTHER
//-------------------------------------------------
virtual bool overlaps(CollisionShape* shape) = 0;
};
}
#endif /* COLLISIONSHAPE_H_ */
and a SphereShape class which extends CollisionShape and implements the methods above
/* SphereShape.h */
#ifndef SPHERESHAPE_H_
#define SPHERESHAPE_H_
#include "CollisionShape.h"
namespace domino
{
class SphereShape : public CollisionShape
{
public:
// CONSTRUCTOR
//-------------------------------------------------
SphereShape();
SphereShape(CollisionShape* shape1, CollisionShape* shape2);
// DESTRUCTOR
//-------------------------------------------------
~SphereShape();
// SETTERS
//-------------------------------------------------
void SetPosition();
void SetRadius();
// GETTERS
//-------------------------------------------------
void GetRadius();
void GetPosition();
void GetSceneNode();
void GetGrowth(CollisionShape* other);
// OTHER
//-------------------------------------------------
bool overlaps(CollisionShape* shape);
};
}
#endif /* SPHERESHAPE_H_ */
and the .cpp file:
/*SphereShape.cpp*/
#include "SphereShape.h"
#define max(a,b) (a>b?a:b)
namespace domino
{
// CONSTRUCTOR
//-------------------------------------------------
SphereShape::SphereShape(CollisionShape* shape1, CollisionShape* shape2)
{
}
// DESTRUCTOR
//-------------------------------------------------
SphereShape::~SphereShape()
{
}
// SETTERS
//-------------------------------------------------
void SphereShape::SetPosition()
{
}
void SphereShape::SetRadius()
{
}
// GETTERS
//-------------------------------------------------
void SphereShape::GetRadius()
{
}
void SphereShape::GetPosition()
{
}
void SphereShape::GetSceneNode()
{
}
void SphereShape::GetGrowth(CollisionShape* other)
{
}
// OTHER
//-------------------------------------------------
bool SphereShape::overlaps(CollisionShape* shape)
{
return true;
}
}
These classes, along some other get compiled into a shared library.
Building libdomino.so
g++ -m32 -lpthread -ldl -L/usr/X11R6/lib -lglut -lGLU -lGL -shared -lSDKUtil -lglut -lGLEW -lOpenCL -L/home/adrian/AMD-APP-SDK-v2.4-lnx32/lib/x86 -L/home/adrian/AMD-APP-SDK-v2.4-lnx32/TempSDKUtil/lib/x86 -L"/home/adrian/AMD-APP-SDK-v2.4-lnx32/lib/x86" -lSDKUtil -lglut -lGLEW -lOpenCL -o build/debug/x86/libdomino.so build/debug/x86//Material.o build/debug/x86//Body.o build/debug/x86//SphereShape.o build/debug/x86//World.o build/debug/x86//Engine.o build/debug/x86//BVHNode.o
When I compile the code that uses this library I get the following error:
../../../lib/x86//libdomino.so: undefined reference to `vtable for domino::CollisionShape'
../../../lib/x86//libdomino.so: undefined reference to `typeinfo for domino::CollisionShape'
Command used to compile the demo that uses the library:
g++ -o build/debug/x86/startdemo build/debug/x86//CMesh.o build/debug/x86//CSceneNode.o build/debug/x86//OFF.o build/debug/x86//Light.o build/debug/x86//main.o build/debug/x86//Camera.o -m32 -lpthread -ldl -L/usr/X11R6/lib -lglut -lGLU -lGL -lSDKUtil -lglut -lGLEW -ldomino -lSDKUtil -lOpenCL -L/home/adrian/AMD-APP-SDK-v2.4-lnx32/lib/x86 -L/home/adrian/AMD-APP-SDK-v2.4-lnx32/TempSDKUtil/lib/x86 -L../../../lib/x86/ -L"/home/adrian/AMD-APP-SDK-v2.4-lnx32/lib/x86"
(the -ldomino flag)
And when I run the demo, I manually tell it about the library:
LD_LIBRARY_PATH=../../lib/x86/:$AMDAPPSDKROOT/lib/x86:$LD_LIBRARY_PATH bin/x86/startdemo
After reading a bit about virtual functions and virtual tables I understood that virtual tables are handled by the compiler and I shouldn't worry about it, so I'm a little bit confused on how to handle this issue.
I'm using gcc version 4.6.0 20110530 (Red Hat 4.6.0-9) (GCC)
Later edit:
I'm really sorry, but I wrote the code by hand directly here.
I have defined the return types in the code.
I apologize to the 2 people that answered below.
I have to mention that I am a beginner at using more complex project layouts in C++.By this I mean more complex makefiles, shared libraries, stuff like that.
My problem was caused by the fact that I didn't define the body of virtual void CollisionShape::GetSceneNode().
The way to fix this is to either define the above function, or declare it as pure virtual as such:
virtual void CollisionShape::GetSceneNode() = 0;
Any non-pure virtual function must be defined, even if it's never used. A missing definition will often result in the 'vtable undefined' linker error, especially when the very first non-pure, non-inline virtual function of a class is left undefined. In your case, CollisionShape::GetSceneNode() is left undefined.
On an unrelated note, every class that has a virtual function needs a virtual destructor, every time, absolutely no exceptions whatsoever. The language unfortunately doesn't enforce this, so it's your responsibility. G++ has a flag, -Weffc++, which enables warnings for this and other common pitfalls, described in the Scott Meyers's book "Effective C++". I strongly recommend using this flag all the time. Using -Werror by default is also a good habit. Suppress individual warnings one by one, and only if there's no possibility to fix the code.
I can't say for certain whether this will fix your compilation error, but in any case you need to declare a virtual destructor (virtual ~CollisionShape()) in your CollisionShape class. Failure to do so will result in undefined runtime behavior when SphereShape is deleted through its base class pointer (a pointer to CollisionShape). Of course, since a virtual constructor is indeed added to a class's vtbl, I guess it's not beyond the realm of possibility that this is the culprit behind your error.
In Effective C++, Scott Meyers has the following to say.
The C++ language standard is unusually clear on this topic. When you try to delete a derived class object through a base class pointer and the base class has a nonvirtual destructor [...], the results are undefined. That means compilers may generate code to do whatever they like: reformat your disk, send suggestive mail to your boss, fax source code to your competitors, whatever. (What often happens at runtimme is that the derived class's destructor is never called. [...])
Due to the conflicting declarations of GetSceneNode, in your current code
virtual void GetSceneNode();
in the base class, and
SceneNode* GetSceneNode();
in the derived class, your code should not compile. You should not get to the linking stage. I'm pretty sure that the code that you're presenting is not your real code.
Hence, I downvoted the question.
But regarding the error that you evidently produced with some other code, it has been asked before on SO, and answered for example here.
Hence, I also voted to close the question.
Cheers & hth.,
This may not be the whole problem, but you are missing a return type on those functions. ie
virtual double GetPosition() = 0;
gsoap with its tools wsdl2h and soapcpp2 provided me with a soapStub.h file containing the following:
class SOAP_CMAC ns2__SOAPKunden
{
public:
std::string *adresszusatz;
// ...
public:
virtual int soap_type() const { return 7; }
// ...
ns2__SOAPKunden() : adresszusatz(NULL), x(NULL) { } // left out all member init.
virtual ~ns2__SOAPKunden() { }
};
I start with a small app using the class to populate objects with data from informix DB.
But to compile successfully i have to leave away all the virtual stuff - i found many postings about this error and use of virtual members in subclasses - otherwise i get
main.o: In function `ns2__SOAPKunden::ns2__SOAPKunden()':
main.cpp:(.text._ZN15ns2__SOAPKundenC1Ev[ns2__SOAPKunden::ns2__SOAPKunden()]+0xf): undefined reference to `vtable for ns2__SOAPKunden'
main.o: In function `ns2__SOAPKunden::~ns2__SOAPKunden()':
main.cpp:(.text._ZN15ns2__SOAPKundenD1Ev[ns2__SOAPKunden::~ns2__SOAPKunden()]+0x13): undefined reference to `vtable for ns2__SOAPKunden'
collect2: ld returned 1 exit status
I admit after years of scripting only it's very hard for me to make sense of C++ code... I want to ask for any advice what to try next. My class is no derived class, is for example what makes me wonder.
The error means that the virtual table has not been correctly compiled/linked in the final binary (executable or library). There are two common circumstances that lead to this error:
you are not linking the object file that includes the virtual table definitions --i.e. you compiled soapStub.cpp into soapStub.o, but did not add that binary to the linker command line.
the compiler is not generating the virtual table anywhere, so even if you are including all object files, that does not include the virtual table.
The second case is the hardest to identify for non-experienced developers, and can be caused by a class that is defined in the header and contains virtual functions. If all the virtual functions are defined inlined, the compiler will generate the virtual table in all translation units that include the header, and mark it as a weak symbol so that the linker can discard them, but if you later add a new virtual method and you leave it undefined in the header --or if you remove the definition from one of the virtual functions--, then the compiler will not generate the virtual table in each translation unit, but only in the one that defines those functions.
Things to check:
you are linking all object files
either all virtual functions are defined inline in the class definition or you have a .cpp that defines the virtual functions and you are linking that in.
This is what David Rodriguez said, just stated simpler I guess...
I had this situation in my interface class:
class IBase
{
public:
virtual void begin(unsigned long);
virtual void end();
virtual int available(void) = 0;
virtual int peek(void) = 0;
virtual int read(void) = 0;
virtual void flush(void) = 0;
}
and changed it to this:
class IBase
{
public:
virtual void begin(unsigned long) = 0;
virtual void end() = 0;
virtual int available(void) = 0;
virtual int peek(void) = 0;
virtual int read(void) = 0;
virtual void flush(void) = 0;
}
which did the trick.
begin() and end() were defined in derived class in a different file, IBase class (interface) was only declared in header and included in few places.
Error from OP only appeared when I set optimizations to none (-O0), any other setting resulted in no error (gcc 4.8).
I'm writing a simple game engine, and I have the EntityComponent.h file:
#ifndef Psycho2D_Core_EntityComponent_
#define Psycho2D_Core_EntityComponent_
#include <string>
namespace psycho2d{
class EntityComponent{
private:
std::string m_name;
public:
EntityComponent(const std::string &name);
virtual ~EntityComponent();
const std::string& getName() const;
virtual void initialize() = 0;
virtual void loadProperties() = 0;
virtual void update() = 0;
virtual void destroy() = 0;
};
}
#endif
And the relative EntityComponent.cpp file:
#include "EntityComponent.h"
#include <string>
psycho2d::EntityComponent::EntityComponent(const std::string &name){
this->m_name = name;
}
psycho2d::EntityComponent::~EntityComponent(){}
inline const std::string& psycho2d::EntityComponent::getName() const{
return this->m_name;
}
These two file are part of a framework (I'm working on a Mac). They compile well.
The problem is when I write an executable that use the library.
I have created a sub-class of EntityComponent, and it compiles. But, if I call the getName() function, the linker tell me:
"psycho2d::EntityComponent::getName() const", referenced from:
_main in main.o
Symbol(s) not found
Collect2: ld returned 1 exit status
What I can do?
Thanks.
Put the code for the inline function in the header file, if you want to reference it from multiple .cpp files.
Reference here.
An external linkage inline function must defined (as effectively the same) in every translation unit where it's used.
So either remove the inline from the definition, or place the definition in the header file.
Cheers & hth.,
Your (slightly modified to include a subclass to text) code compiles fine on my machine (A Mac, too. GCC 4.2.1)
Try removing all .o-files and compile with a clean directory. If that fails too, I'd try to remove the inline-definition.
Try removing the inline qualifier from your implementation.
I'm getting some errors when compiling my program. They relate to the constructor and destructor of my class Instruction.
Errors are:
/tmp/ccSWO7VW.o: In function `Instruction::Instruction(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int)':
ale.c:(.text+0x241): undefined reference to `vtable for Instruction'
/tmp/ccSWO7VW.o: In function `Instruction::Instruction(std::basic_string<char, std::char_traits<char>, std::allocator<char> >, int)':
ale.c:(.text+0x2ab): undefined reference to `vtable for Instruction'
/tmp/ccSWO7VW.o: In function `Instruction::~Instruction()':
ale.c:(.text+0x315): undefined reference to `vtable for Instruction'
/tmp/ccSWO7VW.o: In function `Instruction::~Instruction()':
ale.c:(.text+0x38d): undefined reference to `vtable for Instruction'
collect2: ld returned 1 exit status
Here is my code:
//classses.h
#include <iostream>
#include <string>
using namespace std;
class Instruction{
protected:
string name;
int value;
public:
Instruction(string _name, int _value);
~Instruction();
void setName(string _name);
void setValue(int _value);
string getName();
int getValue();
virtual void execute();
};
//constructor
Instruction::Instruction(string _name, int _value){
name = _name;
value = _value;
}
//destructor
Instruction::~Instruction(){
name = "";
value = 0;
}
void Instruction::setName(string _name){
name = _name;
}
void Instruction::setValue(int _value){
value = _value;
}
string Instruction::getName(){
return name;
}
int Instruction::getValue(){
return value;
}
/////////////////////////////////////////////////////////////////////
//ale.cpp
#include "headers.h"
#include "functions.h"
#include "classes.h"
#include <list>
using namespace std;
int main(){
return 0;
}
I would guess the problem is due to you declaring a virtual method 'execute' in the Instruction class, and never defining it anywhere. Compilers have to produce a vtable object for a class with virtual methods and really only want one copy of it, so they usually just do it in the compilation unit (source file) that defines the first virtual function...
You did not define your virtual function and/or g++ wants you to make your destructor virtual (because you have virtual functions which assumes inheritance)
Try
virtual void execute()=0;
This will make your class abstract, which seems to be what you intend since execute isn't defined.
If you ever want to use Instruction in more than one .cpp file, you should move the implementation of the class methods into a classes.cpp file.
As people already told, the problem is having execute() that is not implemented. Implement it, or make it pure virtual as says Dan Hook.
Just an extra remark: in many (maybe most depending on what you're coding on) cases, you don't need to implement the destructor. You just need if you want some specific functionnality (flushing data to a file for example).
As long as you have no pointer (as it is the case in your code), you won't have any memory tracking issues. Just remove the destructors: it's safe and it's less code.
However, if only one member is a pointer, then everything gets messy and you have to deal with memory management issues, memory leaks and segfaults ;)