Qt: a missing vtable usually means the first non-inline virtual member function has no definition

clang, qt

Solution

Assuming we're dealing with `qmake`.

The golden rules are:

- Make sure the `Q_OBJECT` macro is present in the definition of all `QObject`-derived classes.

- Make sure you declare your `QObject`-derived classes in your header files only.

- Make sure all of your header files are listed in your .pro file in the `HEADERS=` list.

- Run `qmake` every time you add `Q_OBJECT` to one of your classes or modify your `.pro` file.

Explanation

EDIT 1: The error goes away if I comment out Q_OBJECT from the declation of MSFSPlugin::MSFSPluginImpl, but then I lose the signal functionality.

Yup. `Q_OBJECT` is needed for declaring signals, slots, invokables, `qobject_cast`, translations, properties, enums and methods introspection, and so on.

The #1 golden rule comes from the fact that without `Q_OBJECT` you can't use stuff like `qobject_cast` on your class; if you use (even indirectly) introspection facilities, for instance to debug an object hierarchy or to dump all active connections to an object, then objects of your class will have the real class name shown (and not the one of the superclass); etc.

`Q_OBJECT` does two things:

- it tells builsystems to add calls to `moc`, whose job is to generate some extra code for the class. This code will provide all the facilities listed above;

- since it's a normal C++ macro, when compiled it expands to a few declarations, including a couple of virtuals: `qt_metacall()` and `metaObject()`. `moc` will generate the implementation for these virtuals.

The error you get is the typical symptom of having declared the virtuals (because the macro was expanded in your code) but `moc` wasn't run, you had some unimplemented virtuals which will make the linking fail.

With gcc and GNU ld, you get an even more cryptic error, about an `undefined reference to vtable for ClassName`. Of course, googling such errors will immediately tell you how to solve the issue.

EDIT 2: I see moc operates on header files only. Could this be related to the fact that my QObject derived class is declared & defined in a .cpp file?

So, the question is: why wasn't `moc` run on a file containing a definition of a class with the `Q_OBJECT` macro?

When we use `qmake` to generate your Makefiles, then qmake will scan all the header files listed in the `HEADERS` variable. When it finds that a header contains a class definition with the `Q_OBJECT` macro, it will also emit instructions (in the Makefile) to run `moc` over that header, compile `moc`'s output and link the resulting object in the final target.

And we have rules #2, #3, #4 right here.

#2 tells us to put `Q_OBJECT` classes in headers; and that's because `HEADERS` lists headers, not sources.

#3 tells us to indeed put all headers into the `HEADERS` list. That obviously because if a header containing a `Q_OBJECT` is not in that list, then `qmake` won't find it and emit the rules. (While not strictly necessary for headers not containing QObject subclasses, it's good practice to put every header in there in order to forget none.)

#4 tells us to re-run `qmake` every time we add `Q_OBJECT` or modify the `.pro` file. The reason for the first part of the rule is that if `qmake` already scanned a header and found no `Q_OBJECT`, then it didn't emit any rules in the Makefile. But adding `Q_OBJECT` also needs those rules; hence we need `qmake` to re-scan the headers, and that's precisely what re-running `qmake` does.

The same reason applies when the `.pro` is modified (for instance, when adding more headers -- maybe with `Q_OBJECT` under `HEADERS`).

Note that if you're using a GNU-like `make`, then `qmake` will emit a special rule that tells `make` to re-run `qmake` and then restart the Makefile, if the `.pro` gets modified after the Makefile. That's why usually on UNIX you don't need to manually re-run `qmake` when you modify your `.pro` -- just running `make` will also run `qmake` again. But this doesn't work everywhere.

So, is it impossible to have classes definition containing `Q_OBJECT` in a `.cpp` file?

No, it's perfectly possible, but it requires using a somehow undocumented `qmake` feature. The trick is adding a line like:

#include "foobar.moc"

at the end of the `foobar.cpp` file, file that contains one of more class definitions with `Q_OBJECT`.

`qmake` will find this special inclusion and generate a rule for `moc` to create `foobar.moc`, which will then be included by the `.cpp` and thus compiled together with it. (Hence, there will be no extra rules for compiling `foobar.moc` nor to link the result.)

Problem

Original source