I'm using Code::Blocks 8.02 and the mingw 5.1.6 compiler. I'm getting this error when I compile my Qt project:
C:\Documents and Settings\The
Fuzz\Desktop\GUI\App_interface.cpp|33|undefined
reference to `vtable for AddressBook'
File AddressBook.h:
#ifndef ADDRESSBOOK_H
#define ADDRESSBOOK_H
#include <QWidget>
class QLabel;
class QLineEdit;
class QTextEdit;
class AddressBook : public QWidget
{
Q_OBJECT
public:
AddressBook(QWidget *parent = 0);
private:
QLineEdit *nameLine;
QTextEdit *addressText;
};
#endif
File AddressBook.cpp:
#include <QtGui>
#include "addressbook.h"
AddressBook::AddressBook(QWidget *parent)
: QWidget(parent)
{
QLabel *nameLabel = new QLabel(tr("Name:"));
nameLine = new QLineEdit;
QLabel *addressLabel = new QLabel(tr("Address:"));
addressText = new QTextEdit;
QGridLayout *mainLayout = new QGridLayout;
mainLayout->addWidget(nameLabel, 0, 0);
mainLayout->addWidget(nameLine, 0, 1);
mainLayout->addWidget(addressLabel, 1, 0, Qt::AlignTop);
mainLayout->addWidget(addressText, 1, 1);
setLayout(mainLayout);
setWindowTitle(tr("Simple Address Book"));
}
When using Qt Creator:
Build → Run qmake
Build → Rebuild All
Warning: Do not do this if you already have a .pro file - you'll lose it!
In order to automatically ensure that all moc cpp files are generated, you can get qmake to automatically generate a .pro file for you instead of writing one yourself.
Run
qmake -project
in the project directory, and qmake will scan your directory for all C++ headers and source files to generate moc cpp files for.
The problem is almost certainly that you are not compiling or not linking in the generated moc_AddressBook.cpp file. (It should have been generated for you -- you are running Qt's moc on your code before compiling, right?)
To answer a little more thoroughly, the Q_OBJECT macro signals Qt's moc tool to create an extra implementation file that contains the code necessary to support QObject's meta-information system. If you had any signals or slots, it would do a few things for those as well.
An alternative solution might be to remove the Q_OBJECT macro. You probably don't want to do this, but it would help the immediate problem, and it isn't strictly necessary with the code that you've presented.
Also, I would note that your line:
#include "addressbook.h"
Should probably be:
#include "AddressBook.h"
based on how you presented the filenames in the question.
Assuming you are using qmake to generate your Makefile, be sure that AddressBook.h is specified in your .pro file's HEADERS's variable, e.g.
HEADERS = AddressBook.h
For CMake projects, set CMAKE_AUTOMOC to ON, this fixed my problem.
#Find includes in corresponding build directories
set(CMAKE_INCLUDE_CURRENT_DIR ON)
# Instruct CMake to run moc automatically when needed.
set(CMAKE_AUTOMOC ON)
I got this while using pure virtual functions. For example,
virtual void process();
gave this error, while
virtual void process() = 0;
made it go away.
For anyone who's Googling this problem, check that all virtual functions are defined. (via " = 0" or a full definition in the source file)
I'm using Netbeans with the MinGW compiler.
I was running into the same problem using CLion, and solved it by adding these lines to CMakeLists.txt
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTORCC ON)
See https://www.jetbrains.com/help/clion/qt-tutorial.html#qt-setup-in-clion
I had the same problem but as soon as I defined my constructor in the header file instead of the .cpp the error disappeared. Also the corresponding moc file was missing in the file system and in the Makefile section"compiler_moc_header_make_all" . I ran a qmake then finally everything built with succes. I went to check the Makefile and it was there now.
deleted the build folder, restarted Qt Creator and it worked
I come to the same problem, rebuild the project never update the Makefile, I remove the Makefile and rebuild , the the problem is gone.
ps: run 'make' from command line may give you detail information than the IDE, and helpful to get the real problem.
One cause is when you declare a virtual functions in a class and you don't define their body.
In my case Rebuild All was not enough, I had to delete build directory and make Rebuild All - then it worked!
Simply Run qmake for your project. This can easily be done by right-clicking on the name of your project and clicking on Run qmake.
Just clear the project and then rebuild it!
Go to .pro file and make sure .h file has 'include' before it.
HEADERS += include/file.h \
include/file2.h
I had the same problem trying to use a protected virtual function. Two things worked.
Changing void process(); to void process() = 0;
Making process() public instead of private
You will get the same error message if you accidentally add a destructor prototype. Add an empty destructor definition or remove the prototype.
Header files for moc compilation should contained in the HEADERS += ... variable:
I have moved the header files in the Myproject.pro to the SOURCES += ... section, because I want to have mySource.h and mySource.cpp in the same tree element. But that is faulty for QT Creator. In result the error "Undefined reference to vtable" has occured.
It seems to be:
QT detects header for moc compilation only in the HEADERS +=... section (or variable).
See also the correct explaination in the other stackoverflow answer Second anwer "I've seen a lot of ways to solve the problem, but no explanation for why it happens, so here goes.". In my mind this is an exactly explaination of the problem, which has help me to found and solve my problem.
CMake
when using CMake, interestingly enough if my .cpp and .h files are not in the same folder the moc, bu default, fails to generate the meta file :)
the most errors from using Q_OBJECT but not generate moc file
the moc file define
classname::metaObject
staticMetaObject
qt_metacall
Here is a example:
when source or header using Q_OBJECT
/opt/qt/bin/moc ./window.h -o ./moc_window.cpp
Makefile add moc_window.o in OBJS
Ex: OBJS=main.o window.o moc_window.o
try this source
https://www.mediafire.com/file/anjeah1jmm07mfe/qt_group_box.tar.gz
refer to http://fatalfeel.blogspot.com/2013/11/qt5-c-building.html
I am using Qt creator to compile and run my programs, I don't use Qt command prompt often. One thing I did to get rid of the annoying error "vtable something something" is by adding the following lines to .pro file.
TEMPLATE = app
QT += core
I have a header-only library project set up with the cmake command:
add_library(my_library INTERFACE)
and I also added
target_sources(my_library INTERFACE ${MY_LIRBARY_HEADER_FILES})
but when I open a source file, I get the warning:
This file does not belong to any project target, code insight features might not work properly
and I lose a lot of the functionality on things like code completion.
What is the proper way to set this up so CLion provides its usual functionality on a header-only library?
Little background
I was having the same problem, albeit the project was not header-only, nevertheless, the open files from inc folder were throwing the aforementioned warning, even though the CMake file clearly marked that folder to be include_directory.
*.hpp files do not belong to ${SOURCE}
include_directories("${PROJECT_SOURCE_DIR}/inc/")
add_subdirectory(src)
add_executable(${EXECUTABLE_NAME} main.cpp ${SOURCE})
Since this is a perfectly valid CMake file and adding the include files to source files is not idiomatic, I did not want to amend the CMake file.
The solution
As described on the official JetBrains Forum, the CMake file is indeed valid and the warning is shown because of the inability of CLion to properly index header files. The suggested workaround extracted from the link is to right-click the folder and Mark directory as | Library Files/Project Sources and Headers.
So, this header isn't includes in executables and CLion notifies you that some code insight features might not work properly. As workaround you can use "Mark directory as" Library Files/Project Source and Headers for folder.
Clion takes information about source files from CMake build system. When you add any cpp file to sources list CMake automatically tell about header with same name. So if cpp/h names differs (or you don't have cpp file at all) you should include header manually.
set(Sources my_lib.cpp)
set(Headers header_of_my_lib.h)
add_executable(superlib ${Sources} ${Headers})
If you don't have any executable you can omit last line, CLion will still know about files
This warning is an IDE issue that Android Studio cannot recognise the current directory if it does not include any source files.
Workaround
Adding am empty source file, e.g empty_xxx.c under the directory in question and adding below line in your corresponding CMakeList.txt
add_library(${TARGET_NAME_XXX} SHARED ${SOME_DIR_HAVING_THIS_WARNING}/empty_xxx.c)
will help get rid of this warning.
You can add the header files to your project like this:
set(SOURCE_FILES main.cpp MyClass1.cpp MyClass1.h MyClass2.cpp MyClass2.h)
You can also set it in multiple steps like so:
set(SOURCE_FILES main.cpp)
set(SOURCE_FILES ${SOURCE_FILES} MyClass1.cpp MyClass1.h)
set(SOURCE_FILES ${SOURCE_FILES} MyClass2.cpp MyClass2.h)
Though as mentioned in the comments, you probably shouldn't be adding the header files to your project at all.
Question is similar to this question
Handling header files dependencies with cmake
I have sample program dir having main.c main.h and CMakeLists.txt
main.h contents are
#ifndef MAIN_H
#define MAIN_H
int t=3;
int y=2;
#endif
main.c contents are
#include <main.h>
#include<stdio.h>
int main(){
printf("%d apple",t);
}
and CMakeLists.txt
PROJECT( test )
AUX_SOURCE_DIRECTORY(. test_SRCS)
include_directories(.)
ADD_EXECUTABLE (main ${test_SRCS})
but cmake is not rebuilding main.c on modification of header file.
I want it to auto-generate header file dependency.
Is it possible using cmake ?
if not is there any other tool which can do that ?
As mentioned in my comment, I have tried out your example and things were working fine: if main.h was modified then main.c would be recompiled.
My installation of CMake (version 2.8.0) told me to add
cmake_minimum_required(VERSION 2.8)
to the CMakeLists.txt file, but that is all of the adjustments I needed.
Answering this for others that google search...
I ran into this problem with one of my projects. As it turns out I added the header to the cpp file after running cmake. Re-running cmake fixed the problem. If you run into this, try that and see if it fixes the issue.
From the cmake 2.8.0 documentation of AUX_SOURCE_DIRECTORY:
It is tempting to use this command to avoid writing the list of source
files for a library or executable target. While this seems to work,
there is no way for CMake to generate a build system that knows when a
new source file has been added. Normally the generated build system
knows when it needs to rerun CMake because the CMakeLists.txt file is
modified to add a new source. When the source is just added to the
directory without modifying this file, one would have to manually
rerun CMake to generate a build system incorporating the new file.
Why do you want to avoid creating a list of files? Such lists generally do not change frequently.
I have created a project which consists of a main.cpp file and another class (named Physical) that is broken up into a Physical.hpp file and Physical.cpp file.
The project file structure looks like this:
main.cpp
header/Physical.hpp
src/Physical.cpp
The project compiles fine, but only if I include Physical.hpp in different ways depending on whether or not I'm including from the Physical.cpp or main.cpp file.
From the main file, I have to use:
#include "header/Physical.hpp"
Whereas, from the Physical.cpp file I have to use:
#include "../header/Physical.hpp"
Why is there this discrepancy? I expect it has something to do with my cmake configuration file, although I'm really not sure. Below is my cmake config file.
cmake_minimum_required(VERSION 2.8.4)
project(gravity_simulator ${PROJECT_BINARY_DIR})
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(SOURCE_FILES main.cpp src/Physical.cpp)
include_directories("${PROJECT_BINARY_DIR}")
add_executable(gravity_simulator ${SOURCE_FILES})
# Detect and add SFML
set(CMAKE_MODULE_PATH "/usr/share/SFML/cmake/Modules/" ${CMAKE_MODULE_PATH})
#Find any version 2.X of SFML
#See the FindSFML.cmake file for additional details and instructions
find_package(SFML 2 REQUIRED system window graphics network audio)
if(SFML_FOUND)
include_directories(${SFML_INCLUDE_DIR})
target_link_libraries(gravity_simulator ${SFML_LIBRARIES})
endif()
Everything works as expected.
For your main.cpp file the header is located at header/Physical.hpp while for your Physical.cpp the header is located at ../header/Physical.hpp.
The mistake here is, that you think the relative path would always start from a specific directly, while instead every source file (*.cpp) gets compiled independently and thus the header search is happening for each file independently.
Personally if I don't write a library, I simply put all my source and header files in a src directory and everything will be fine. However if I'm writing a library, I use the <header.hpp> style and add the header directory to the include directory (include_directories("header")). The whole reason why one usually splits up things into header and source files is, so when one ships a library one can easily just ship the headers and doesn't have manually filter them out between the source files.
tl;dr When writing an application put everything a source directory. When writing a library, use the <> for the inclusion add the header directory to the include directories.
I have a ROS package that includes QT4 GUIs. My code is in the folder
Project_name/src/test/*.cpp
and my includes in
Project_name/include/test/*.h
Some qt4 mocs must be created as some header files contain Q_OBJECT in their classes.
I tried the
set(CMAKE_AUTOMOC ON)
in the cmake file but as it seems it does not search the /include/test/ folder. AUTOMOC states that works either bu searching the source files for moc_**.cpp files or by examining the header files for Q_OBJECT.
I also tried to include a moc_***.cpp in a source file (for example /src/test/a.cpp). So it searched for a.h but could not find it in include/test/a.h.
I must note that if I remove the Q_OBJECT from the classes the compilation succeeds, as the include/ folder is added like this:
include_directories( include
${catkin_INCLUDE_DIRS}
)
Finally I've tried to use QT4_WRAP_CPP but for some reason it couldn't find the mocs as well and the link failed (although in another project with the same parameters in the cmake file works :/)
Edit :
Found a solution. In added in the cpp file:
#include "../../include/test/moc_a.cpp"
and found the .h in include/test.
Though something tells me that it is not the correct way :P
#include "../../include/test/moc_a.cpp" in cpp file works but not well for libraries that may be built sometimes as static libraries within bigger project and sometimes by themselves. The problem is that include directory can be created in a not-suitable location, which pollutes code, causes problems with VCS.
qt_wrap_cpp works best for me. It supports both qt4 and qt5, does not require including moc in cpp file. The syntax:
include_directories(${CMAKE_CURRENT_BINARY_DIR}) # including binary dir is
# necessary only if there are classes with Q_OBJECT macro declared in cpp
# files (these cpp files should also contain `# include "x.moc"` at the end).
set(CMAKE_AUTOMOC ON)
include_directories(${Include_Directories})
set(Sources ${Sources_Path}/a.cpp ${Sources_Path}/b.cpp
... ${Sources_Path_z}/z.cpp)
qt_wrap_cpp(${Target_Name} Sources ${Headers_Path}/header1.hpp
${Headers_Path_2}/header2.hpp ... ${Headers_Path_N}/headerN.hpp)
add_library(${Target_Name} STATIC ${Sources})
# OR add_executable(${Target_Name} ${Sources})
Naturally, only headers that contain Q_OBJECT macro and are not in the same directory as corresponding sources must be passed to qt_wrap_cpp.