72

I'm setting up a C++ project, on Ubuntu x64, using Eclipse-CDT. I'm basically doing a hello world and linking to a commerical 3rd party library.

I've included the header files, linked to their libraries, but I still get linker errors. Are there some possible problems here other than the obvious (e.g. I am 99% sure I'm linking to the correct library).

  1. Is there a way to confirm the static libraries I am linking to are 64bit?
  2. Is there a way to confirm that the library has the class (and methods) I am expecting it to have?

Eclipse says:

Building target: LinkProblem
Invoking: GCC C++ Linker
g++ -L/home/notroot/workspace/somelib-3/somelib/target/bin -o"LinkProblem"  ./src/LinkProblem.o   -lsomelib1 -lpthread -lsomelib2 -lsomelib3
./src/LinkProblem.o: In function `main':
/home/notroot/workspace/LinkProblem/Debug/../src/LinkProblem.cpp:17: undefined reference to `SomeClass::close()'
./src/LinkProblem.o: In function `SomeOtherClass':
/home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:148: undefined reference to `SomeClass::SomeClass()'
/home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:148: undefined reference to `vtable for SomeOtherClass'
/home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:151: undefined reference to `SomeClass::~SomeClass()'
./src/LinkProblem.o: In function `~SomeOtherClass':
/home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:140: undefined reference to `vtable for SomeOtherClass'
/home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:140: undefined reference to `SomeClass::~SomeClass()'
/home/notroot/workspace/somelib-3/somelib/include/sql/somefile.h:140: undefined reference to `SomeClass::~SomeClass()'
collect2: ld returned 1 exit status
make: *** [LinkProblem] Error 1
waterlooalex
  • 13,642
  • 16
  • 78
  • 99

12 Answers12

168

This linker error usually (in my experience) means that you've overridden a virtual function in a child class with a declaration, but haven't given a definition for the method. For example:

class Base
{
    virtual void f() = 0;
}
class Derived : public Base
{
    void f();
}

But you haven't given the definition of f. When you use the class, you get the linker error. Much like a normal linker error, it's because the compiler knew what you were talking about, but the linker couldn't find the definition. It's just got a very difficult to understand message.

mgiuca
  • 20,958
  • 7
  • 54
  • 70
74

Assuming those methods are in one of the libs it looks like an ordering problem.

When linking libraries into an executable they are done in the order they are declared.
Also the linker will only take the methods/functions required to resolve currently outstanding dependencies. If a subsequent library then uses methods/functions that were not originally required by the objects you will have missing dependencies.

How it works:

  • Take all the object files and combine them into an executable
  • Resolve any dependencies among object files.
  • For-each library in order:
    • Check unresolved dependencies and see if the lib resolves them.
    • If so load required part into the executable.

Example:

Objects requires:

  • Open
  • Close
  • BatchRead
  • BatchWrite

Lib 1 provides:

  • Open
  • Close
  • read
  • write

Lib 2 provides

  • BatchRead (but uses lib1:read)
  • BatchWrite (but uses lib1:write)

If linked like this:

gcc -o plop plop.o -l1 -l2

Then the linker will fail to resolve the read and write symbols.

But if I link the application like this:

gcc -o plop plop.o -l2 -l1

Then it will link correctly. As l2 resolves the BatchRead and BatchWrite dependencies but also adds two new ones (read and write). When we link with l1 next all four dependencies are resolved.

Flow
  • 23,572
  • 15
  • 99
  • 156
Martin York
  • 257,169
  • 86
  • 333
  • 562
  • Are you referring to the order of the lib files on the G++ command line? – waterlooalex Jul 07 '09 at 23:14
  • I notice your example uses "gcc" whereas my question uses "g++", should I use "gcc" instead? – waterlooalex Jul 07 '09 at 23:21
  • 2
    No use what you were using.If your code contains C++ stuff you will need to use g++ to get the correct standard libraries. – Martin York Jul 07 '09 at 23:25
  • 3
    this really helped me! My groupproject suddenly stopped accepting new cpp files from one of my libs, it was all about undefined reference, then I switched positions and it worked as a charm. Seriously, there should be a more specific article on some pages out there about this issue. Thanks a lot Martin! – Jonathan May 24 '10 at 01:49
  • @Tux-D What if Lib1's `Open` used a function from Lib2, say `BatchOpen`. Would you have to do `gcc -o plop plop.o -l2 -l1 -l2` or something like that? – Thomas Sep 28 '11 at 02:50
  • @Thomas: No. Because `BatchOpen()` would have already been linked into the application (because it is already required) after the first `-l2`. Thus when you link `-l1` the dependency is satisfied with what is already in the application, thus it is not required to link l2 again. – Martin York Sep 28 '11 at 05:20
  • @Tux-D: But wait, wouldn't the linker only learn about `BatchOpen()` being required when it parses Lib1? Or the other way around: when the linker goes through Lib2 (via `-l2`) why would it incorporate the `BatchOpen` code at that point since it has not even seen the requirement for it that stems from Lib1's `Open`? – Thomas Oct 03 '11 at 03:37
  • @Thomas: Try it. Application requires (Open, Close, BatchRead, BatchWrite). Now you link l2. Because it required both BatchRead/BatchWrite they are added to the application and they are removed from the dep list (and their dependencies added). So now it needs (Open, Close, Read, Write). Now you link l1. Because it requires Open/Close/Read/Write they are added to the application and they are removed from the dep list. If Open also requires `BatchOpen` the linker sees that this function has already been added (from l2) and links it appropriately. – Martin York Oct 03 '11 at 04:27
  • @Tux-D: Thanks a lot. I can follow and understand your description until "`BatchOpen` the linker sees that this function has already been added (from l2)". What I don't understand is why that function would have been added previously. According to your comment, the following symbols have been on the dependency list at some point: `BatchRead,BatchWrite,Open,Close,Read,Write`. Why should the linker have cared about `BatchOpen` until now? – Thomas Oct 05 '11 at 05:45
  • @Tux-D: I'm actually asking this because I did run into a situation in a more complex setup where I noticed that a certain library had been added twice to the script that invoked the linker. Thinking that should hardly be necessary, I removed the second `-llibrary` parameter, but the program would not link any more. So I put it back in and removed the first occurrence of `-llibrary` in the parameter list, and again it would not link - it only did so successfully when the library was given twice. This was using gcc 4.5.2. – Thomas Oct 05 '11 at 05:47
  • @Thomas: It is quite possible to have circular reference in real code where you need to put a library twice. But that does not apply to this situation or the one you suggested. – Martin York Oct 05 '11 at 07:17
  • The following answer regarding overridden virtual declarations without matching definitions should really be the 'accepted' answer - this answer is true, but it's more of an ephemeral edge case than the other answer, which chomps on people much more often :-) – Mark Mullin Feb 22 '13 at 00:42
  • @MarkMullin: Hi Mark welcome to SO. Comments on a answers get flagged to the person that answered them. If you want the original poster to see the comment you should probably post a comment on the question and explain in more meaningful way why your opinion is more important than theirs. This may induce them to change the accepted answer. In my experience this is more likely to be the problem (linker problems usually come during linking (test code will usually find missing definitions long before you start building the libraries)) and **more importantly** solved the problem the OP had. – Martin York Feb 22 '13 at 00:56
  • Is there no linker option to tell "wait until the end before removing symbols"? – ABu Jan 11 '17 at 23:13
  • @Peregring-lk Its not don't remove reference. The linker only imports symbols from a static library it needs to resolve currently outstanding dependencies. – Martin York Jan 11 '17 at 23:49
53

Qt C++ will show this error when you change a class such that it now inherits from QObject (ie so that it can now use signals/slots). Running qmake -r will call moc and fix this problem.

If you are working with others via some sort of version control, you will want to make some change to your .pro file (ie add/remove a blank line). When everyone else gets your changes and runs make, make will see that the .pro file has changed and automatically run qmake. This will save your teammates from repeating your frustration.

Rick Smith
  • 9,031
  • 15
  • 81
  • 85
14

The problem for me turned out to be pretty obscure. My class looked like this:

//-----------------------------------------
// libbase.h
class base {
public:
   base() { }
   virtual ~base() { }

   virtual int foo() { return 0; }
};
//-----------------------------------------

//-----------------------------------------
// libbase.cpp
#include "libbase.h"
//-----------------------------------------

//-----------------------------------------
// main.h
class derived : public base {
public:
    virtual int foo() ;
};
//-----------------------------------------

//-----------------------------------------
// main.cpp
int main () {
    derived d;
}
//-----------------------------------------

The problem is in the linker. My header file went in a library somewhere, but all the virtual functions were declared 'inline' in the class declaration. Since there was no code using the virtual functions (yet), the compiler or linker neglected to put actual function bodies in place. It also failed to create the vtable.

In my main code where I derived from this class, the linker tried to connect my class to the base class and his vtable. But the vtable had been discarded.

The solution was to declare at least one of the virtual functions' bodies outside the class declaration, like this:

//-----------------------------------------
// libbase.h
class base {
public:
   base() { }
   virtual ~base() ;   //-- No longer declared 'inline'

   virtual int foo() { return 0; }
};
//-----------------------------------------

//-----------------------------------------
// libbase.cpp
#include "libbase.h"
base::~base() 
{
}
//-----------------------------------------
Phil Hord
  • 12,780
  • 1
  • 26
  • 30
9

In regards to problems with Qt4, I couldn't use the qmake moc option mentioned above. But that wasn't the problem anyway. I had the following code in the class definition:

class ScreenWidget : public QGLWidget
{
   Q_OBJECT        // must include this if you use Qt signals/slots
...
};

I had to remove the line "Q_OBJECT" because I had no signals or slots defined.

mschachter
  • 91
  • 1
  • 1
8

I had this error message. The problem was that I declared a virtual destructor in the header file, but the virtual functions' body was actually not implemented.

lukeinchina
  • 81
  • 1
  • 3
5

This error will also occur when we simply declare a virtual function without any definition in the base class.

For example:

class Base
{
    virtual void method1(); // throws undefined reference error.

}

Change the above declaration to the below one, it will work fine.

class Base
{
    virtual void method1()
    {
    }
}
Lundin
  • 195,001
  • 40
  • 254
  • 396
user2376546
  • 51
  • 1
  • 2
  • This really worked for me! Can you explain why ths happens? I have seen many classes where a virtual function is declared without curly braces. – kunal18 Jun 08 '15 at 16:28
  • @stalin if you declare if without curly braces, that means you're going to implement it somewhere else (usually in the .cpp file). – Ven Nov 16 '15 at 17:05
4

In my case the problem occured when i forgot to add the =0 on one function in my pure virtual class. It was fixed when the =0 was added. The same as for Frank above.

class ISettings
{
public: 
    virtual ~ISettings() {};
    virtual void OKFunction() =0;
    virtual void ProblemFunction(); // missing =0   
};

class Settings : ISettings
{
    virtual ~Settings() {};
    void OKFunction();
    void ProblemFunction(); 
};

void Settings::OKFunction()
{
    //stuff
}

void Settings::ProblemFunction()
{
    //stuff
}
Lars Persson
  • 104
  • 4
1

I stumbled across the issue now, too. The application defined a pure virtual interface class and a user-defined class provided through a shared lib was supposed to implement the interface. When linking the application, the linker complained that the shared lib would not provide vtable and type_info for the base class, nor could they be found anywhere else. Turned out that I simply forgot to make one of the interface's methods pure virtual (i.e. omitted the " = 0" at the end of the declaration. Very rudimentary, still easy to overlook and puzzling if you can't connect the linker diagnostic to the root cause.

frank
  • 11
  • 1
0

If you have a base class with pure virtual function, make sure your base class constructor and destructor has body otherwise linker fails.

sumeet
  • 1
  • It actually has nothing to do with the constructor or destructor. Not having those will give you a general linker fail. You have to be missing a virtual method to get a linker error on the vtable. – Mysticial Mar 24 '14 at 17:42
0

I put this for future visitors:

if you are receiving the error on creating an Exception object, then the cause of it probably is a lack of definition for what() virtual function.

Mostafa Talebi
  • 8,825
  • 16
  • 61
  • 105
0

I had this error message when trying "hello world" like things with Qt. The problems went away by correctly running the qt moc (meta object compiler) and compiling+including these moc-generated files correctly.

awallin
  • 11
  • 1