Unresolved external symbol "public: virtual struct QMetaObject const * __thiscall Parent

I inherited a class from QObject :

class Parent: public QObject
{
Q_OBJECT
QObject* cl;

public:
Parent(QObject *parent=0):QObject(parent) {
cl = NULL;
}

QObject* getCl() const {
return cl;
}
void setCl(QObject *obj) {
cl = obj;
}
};


But when I write :

Parent ev;


I get the following error:

main.obj:-1: error: LNK2001: unresolved external symbol "public: virtual struct QMetaObject const * __thiscall Parent::metaObject(void)const " (?metaObject@Parent@@UBEPBUQMetaObject@@XZ)

main.obj:-1: error: LNK2001: unresolved external symbol "public: virtual void * __thiscall Parent::qt_metacast(char const *)" (?qt_metacast@Parent@@UAEPAXPBD@Z)

main.obj:-1: error: LNK2001: unresolved external symbol "public: virtual int __thiscall Parent::qt_metacall(enum QMetaObject::Call,int,void * *)" (?qt_metacall@Parent@@UAEHW4Call@QMetaObject@@HPAPAX@Z)


18 Answers
18

You should delete the debug folder of your application and run it again to correct this problem.

debug

I'm having the same issue. Deleting the debug folder didn't help. Any more ideas?
– Vern Jensen
Mar 27 '13 at 0:22

@Vern Jensen, check for Q_OBJECT macro, then rebuild, then delete debug/release folder (to delete all moc files) and rebuild again. One of this should help.
– SpongeBobFan
Jul 3 '13 at 6:26

Q_OBJECT

removal of Q_OBJECT macro from the class, save and adding Q_OBJECT again worked for me when using the QT5 Plugin for VS 2012
– Beachwalker
Dec 16 '13 at 10:43

The above fixed my issue.... but why?
– gnielsen
Mar 12 '15 at 17:19

I was having the same issue for a class project. I found that flat out removing Q_OBJECT macro fixed my problem. No idea why. But if I put it back I receive the same 3 unresolved errors. I fixed that problem by including the new classes inside of the .pro file for QT and the cmakelists.txt file I'm using. Once I included the header and the cpp files the code worked with QObject.
– Callat
Feb 27 '17 at 4:44

Q_OBJECT

.pro

cmakelists.txt

QObject

If you're using Visual Studio, delete the line Q_OBJECT from the header file, save the file, put Q_OBJECT back into the header file, save the file again. This should generate the moc_* file and should build and link correctly.

Q_OBJECT

Q_OBJECT

moc_*

None of the other solutions worked for me but this did! Thanks! ;)
– zeFree
Dec 5 '14 at 11:14

If you're using CMake, ensure that you have set(CMAKE_AUTOMOC ON)
– Matt
Jan 6 '17 at 16:22

set(CMAKE_AUTOMOC ON)

this answer should also be noted as a valid answer !
– Adiel Yaacov
Apr 24 '17 at 13:21

Unlike the name suggest, Rebuild Project will not wipe out everything and build from scratch. If you recently added QObject to your class, you'll have to run qmake again, e.g.

Rebuild Project

QObject

qmake

This is because, by default, qmake only runs when you do significant changes to your solution like adding new source files or modify the .pro file. If you make edits to an existing file, it doesn't know it needs to run qmake. However, changing the QObject-ness of a class definitely requires running qmake again.

qmake

.pro

qmake

qmake

If you're extremely paranoid, then, you can delete the Debug or Release folder. This will definitely force Qt to build everything from scratch.

Debug

Release

If your moc files are generated in the visual studio project try to include them into project if they are not included into project then rebuild.

Why would that be necessary?
– lpapp
Dec 25 '14 at 12:09

Because of some wrong configuration of VS preventing usage of moc files. Sometimes even if it generates moc files correctly but because they are not included, it behave like it does not exist
– Akın Yılmaz
Dec 25 '14 at 12:12

So the issue was I needed the Qt MOC compiler to compile my .h file. This is required for any classes that extend QObject or one of its children. The fix involed (for me) right-clicking on the header file, choosing Properties, and setting the Item Type to "Qt MOC Input", then hitting "Compile" on the header, and then adding the resulting moc_myfilename.cpp file to my project.

Where exactly do you find this "properties"? In Qt Creator I do not see anything like this on right click.
– Horst Walter
Jul 19 '13 at 17:17

This is in XCode, right-clicking on the file listed in the "Navigator" view (the list of files your project uses).
– Vern Jensen
Jul 30 '13 at 18:14

This is possible in Visual Studio as well, but someone else would have to tell you exactly how to configure it there. (I'm sure you can find the answer on Qt's website.)
– Vern Jensen
Jul 30 '13 at 18:22

Also have the problem in QtCreator 3.1.0 (opensource). My QtObject derived class is in main.cpp. I cannot see any moc_. files in debug folder. Does that mean, I am forced to add the QtObject derived class into a header file to get it working?
– BitTickler
May 14 '14 at 15:38

For giggles, I added a header file and a .cpp file and moved my QtObject derived class into it, then also had to #include <QtObject> in the header file and suddenly it worked. Those things should really be documented somewhere....
– BitTickler
May 14 '14 at 15:51

I had the same problem in Visual Studio, and solved it by taking the following steps:

Then in the Custom Build Tool configuration:

set "Command Line" to:

"$(QTDIR)binmoc.exe" "%(FullPath)" -o ".GeneratedFiles$(ConfigurationName)moc_%(Filename).cpp" "-fStdAfx.h" "-f../../../src/FileName.h" -DUNICODE -DWIN32 -DWIN64 -DQT_DLL -DQT_NO_DEBUG -DNDEBUG -DQT_CORE_LIB -DQT_GUI_LIB -DQT_WIDGETS_LIB -DQT_NETWORK_LIB -DWIN32_LEAN_AND_MEAN -DDIS_VERSION=7 -D_MATH_DEFINES_DEFINED "-I.SFML_STATIC" "-I.GeneratedFiles" "-I." "-I$(QTDIR)include" "-I.GeneratedFiles$(ConfigurationName)." "-I$(QTDIR)includeQtCore" "-I$(QTDIR)includeQtGui" "-I$(QTDIR)includeQtNetwork"

set "Outputs" to:

.GeneratedFiles$(ConfigurationName)moc_%(Filename).cpp

set "Additional Dependencies" to:
$(QTDIR)binmoc.exe;%(FullPath)

Your exact values may be different. They are usually applied via a Qt plugin.

I use CMake to manage Qt projects and the new Q_OBJECT needs to be added under the QT4_WRAP_CPP call. This will generate the moc_*.cxx for inclusion in the project and clean up the unresolved externals.

I had this problem with Visual Studio 2012 when I had a Q_OBJECT class definition in my cpp file. Moving the class definition to the header file resolved the issue.

It looks like it should be possible to support Q_OBJECT class in cpp file by adding the cpp file to moc but I did not try this.

This was my problem as well. Annoying to have to expose an internal class in the header file though.
– Zitrax
Jun 2 '17 at 8:46

This works in my case
– Albertino80
Feb 21 at 17:27

In my case (using QtAdd-in with VS2012 and Qt v4.8.4) none of the above suggestions worked.
For some reason VS could not generate proper moc files (build output: No relevant classes found. No output generated.) and when I compiled relevant headers by hand (setting qt moc as a compiler and clicking 'Compile') it produced empty moc file.

What did work was to compile all necessary mocs from command line (moc -o moc_SomeClass.cpp SomeClass.h) and then replace the wrong ones in GeneratedFiles folder.

This is only workaround (and not a convenient one for a big project) to have your project build succesfully, but does not really explain strange VS/QtAdd-in behaviour.

Using QtAdd-in with VS2010 i realized the moc_*.cpp files were updated in the GeneratedFiles/Debug folder although i was in release mode. Copying the files into the Release folder worked for me.

I added cpp/ui files to my project manually, but forgot to add the header file explicitly as header file. Now when compiling I got a similar error message as above and the moc_*.cpp file(s) were not generated in the debug (or release) directory of the build. That was not such an obvious mistake, qmake did not complain and other than the linker message I got no errors.

So if anyone encounters the same problem again (or makes the same copy & pase mistake): make sure the header files have also been added to your project file

I had this problem with a "private class". Qt uses this model though out their code. I have come to really like it myself.

Basically, you have a privately declared class in a public header file class definition, with a pointer to an instance of it as a data member of the public class. (Note: You might find life easier to declare it as a friend class too.)

Then, create the private version of your class within the cpp file for the public one. Do NOT create a header file for this private class. Do all the dirty work with that class. This hides all the implementation of your public class including other private members.

Without explaining that further, here's the point as it relates to this thread. To get Q_OBJECT work, I needed to add this to the cpp:

#include "MyPublicClass.moc"


The cpp layout goes like this:

This happened to me recently when switching from MingW to MSVC. I had a prototyped class/struct listed as a class, and MingW didn't mind.

MSVC definitely sees a difference between class and struct when prototyping is concerned.

class

struct

Hope that helps someone else one day.

In my case, none of the above worked but it was totally my mistake.

I had overrided virtual functions in .h file (declared them) but had never defined them in .cpp :)

I solved my problem by adding this to my header file :

#ifndef MYCLASSNAME_H
#define MYCLASSNAME_H

... // all the header file content.

#endif


Either answer works for me in the VS 2013 environment. I eventually solve the problem by removing the .h/.cpp from project, and adding it back.

I am working in VS2015 with an integrated Perforce p4v client.
In my case Perforce tried to add moc file to a depo, when I reverted this operation, Perforce removed this moc file from project and deleted it.
The file was recreated after the next compilation, but it wasn't included in project, I have to add it manually to Generated files, when I finally understood what was the problem.

I have the same problem, my solution was the encoding( my file with "UTF16LE BOM" can't generate with moc.exe ) , y create another file with ASCII enconding and it work.

HxD HexEditor can help you to see the codification.

Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).


Would you like to answer one of these unanswered questions instead?