Seg Fault creating new QTcpSocket - qt

I'm getting a segmentation fault when I try to create a new QTcpSocket:
QTcpSocket* socket = new QTcpSocket();
When I run I see the following:
$ ./hello
Hello World
Segmentation fault (core dumped)
I'm using Qt 5.11 on Unbuntu 17.04 and I'm not using qmake. I have created my own Makefile. I've checked and double checked the includes and libraries to for Qt 5.11 but not really sure if that is the issue because I can compile, link, and run just fine.
There seem to be 2 sets of areas where the Qt distribution resides which caused some confusion:
$(HOME)Qt5.11.1/5.11.1/gcc_64
/usr/include/x86_64-linux-gnu/qt5
Here is my Makefile and code.
hello.h
#ifndef HELLO_H
#define HELLO_H
#include <QObject>
#include <QTcpSocket>
class hello : public QObject
{
Q_OBJECT
public:
explicit hello(QObject *parent = 0);
signals:
int test();
public slots:
private:
private slots:
};
#endif // HELLO_H
hello.cpp
#include "hello.h"
#include <QTcpSocket>
#include <QDebug>
hello::hello(QObject *parent) :
QObject(parent)
{
qDebug() << "Hello World\n";
QTcpSocket* socket = new QTcpSocket(this);
emit test();
}
main.cpp
#include <QCoreApplication>
#include "hello.h"
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
hello h;
return a.exec();
}
Makefile
####### Compiler, tools and options
CC = g++
DEFINES = -DQT_DEPRECATED_WARNINGS -DQT_NO_DEBUG -DQT_CORE_LIB
CFLAGS = -Wall -W -D_REENTRANT -fPIC $(DEFINES)
INCPATH = -I. \
-I$(HOME)/Qt5.11.1/5.11.1/gcc_64/include \
-I$(HOME)/Qt5.11.1/5.11.1/gcc_64/include/QtCore \
-I$(HOME)/Qt5.11.1/5.11.1/gcc_64/include/QtNetwork \
-I$(HOME)/Qt5.11.1/5.11.1/gcc_64/mkspecs/linux-g++
LINK = g++
LFLAGS = -Wl,-O1 -Wl,-rpath,$(HOME)/Qt5.11.1/5.11.1/gcc_64/lib
LIBS = -L$(HOME)Qt5.11.1/5.11.1/gcc_64/lib \
-L/usr/include/x86_64-linux-gnu/qt5/QtCore \
-L/usr/include/x86_64-linux-gnu/qt5/QtNetwork \
-lQt5Core -lQtNetwork
MOC = $(HOME)Qt5.11.1/5.11.1/gcc_64/bin/moc
####### Files
HEADERS = hello.h
SOURCES = hello.cpp \
main.cpp
OBJECTS = hello.o \
main.o
SRCMOC = moc_hello.cpp
OBJMOC = moc_hello.o
TARGET = hello
####### Implicit rules
.SUFFIXES: .cpp
.cpp.o:
$(CC) -c $(CFLAGS) $(INCPATH) -o $# $<
####### Build rules
all: $(TARGET)
$(TARGET): $(OBJECTS) $(OBJMOC)
$(LINK) $(LFLAGS) -o $(TARGET) $(OBJECTS) $(OBJMOC) $(LIBS)
moc: $(SRCMOC)
clean:
-rm -f $(OBJECTS) $(OBJMOC) $(SRCMOC) $(TARGET)
-rm -f *~ core
####### Compile
hello.o: hello.cpp \
hello.h \
main.o: main.cpp \
hello.h \
moc_hello.o: moc_hello.cpp \
hello.cpp \
moc_hello.cpp: hello.h
Here is the output of "ldd hello":
anshah#anshah-linux-laptop:~/test/hello$ ldd hello
linux-vdso.so.1 => (0x00007fff2bff4000)
libQt5Core.so.5 => /home/anshah/Qt5.11.1/5.11.1/gcc_64/lib/libQt5Core.so.5 (0x00007f5c4b903000)
libQtNetwork.so.4 => /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4 (0x00007f5c4b582000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f5c4b1fa000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f5c4afe3000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5c4ac1c000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f5c4a9fc000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5c4a7e0000)
libicui18n.so.56 => /home/anshah/Qt5.11.1/5.11.1/gcc_64/lib/libicui18n.so.56 (0x00007f5c4a347000)
libicuuc.so.56 => /home/anshah/Qt5.11.1/5.11.1/gcc_64/lib/libicuuc.so.56 (0x00007f5c49f8f000)
libicudata.so.56 => /home/anshah/Qt5.11.1/5.11.1/gcc_64/lib/libicudata.so.56 (0x00007f5c485ac000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f5c483a8000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f5c481a4000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f5c47e90000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f5c47b87000)
/lib64/ld-linux-x86-64.so.2 (0x000056357a3b1000)
libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4 (0x00007f5c47695000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f5c47422000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f5c47218000)

There seem to be 2 sets of areas where the Qt distribution resides which caused some confusion:
That is very likely the root cause of your crash. If you compile against sources (header files) from one version of Qt, and then at run time use different version, a crash is very likely.
However, the root cause appears to be different: you are using two versions of libQtCore:
libQt5Core.so.5 => /home/anshah/Qt5.11.1/5.11.1/gcc_64/lib/libQt5Core.so.5
libQtNetwork.so.4 => /usr/lib/x86_64-linux-gnu/libQtNetwork.so.4
libQtCore.so.4 => /usr/lib/x86_64-linux-gnu/libQtCore.so.4
If these libraries define the same symbols (which seems very likely), then you are almost guaranteed to have a bad time due to symbol conflicts and/or wrong symbol being used.
The libQtCore.so.4 is likely brought in as a dependency of libQtNetwork.so.4, and you probably shouldn't depend on libQtNetwork.so.4 at all.
Your Makefile has:
-lQt5Core -lQtNetwork
The last entry should probably be -lQt5Network instead.

Related

Qt - can't find linker symbol for virtual table for `QCoreApplication' value - error in hello world program

Editing to incorporate tips from comments...
I am unable to run a simple hello world program, encountering the error message:
can't find linker symbol for virtual table for `QCoreApplication' value
I will add that this feels like a case where I need to just reinstall everything from the ground up, but I am hesitant to do so, as I have followed long, detailed instructions to get Qt set up to cross compile on an embedded board. If I can find out what the issue is here and proceed, I will be in good shape to work in my embedded environment going forward.
Here is the source:
main.cpp
#include <QCoreApplication>
#include <iostream>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
std::cout << "Hello World!";
return a.exec();
}
CMakeLists.txt
cmake_minimum_required(VERSION 3.14)
project(demo2 LANGUAGES CXX)
# Probably want to comment this out once we are not debugging the build.
set(CMAKE_VERBOSE_MAKEFILE ON)
set(CMAKE_INCLUDE_CURRENT_DIR ON)
set(CMAKE_AUTOUIC ON)
set(CMAKE_AUTOMOC ON)
set(CMAKE_AUTORCC ON)
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
find_package(Qt5 REQUIRED COMPONENTS Core )
message("\n\n********** Qt5Core_DIR ${Qt5Core_DIR}\n\n")
message("\n\n********** CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}\n\n")
# Not your situation, but in case you have a different linker
# set(CMAKE_EXE_LINKER_FLAGS "-Wl,--verbose")
# Clang passes flags through to the linker (likely ld) by
# set(CMAKE_EXE_LINKER_FLAGS "-Xlinker -v")
# Clang passing flags to the linker (likely ld) AND using -v itself to show how it calls the linker
set(CMAKE_EXE_LINKER_FLAGS "-Xlinker -v -v")
message("\n\n********** CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS}\n\n")
#-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON
add_executable(demo2
main.cpp
)
target_link_libraries(demo2 Qt5::Core )
I am wondering if there is an issue with there being multiple/mismatching libQt5Core library files. Here is some library info:
ldd demo2
linux-vdso.so.1 (0x00007ffe802d2000)
libQt5Core.so.5 => /home/dan/Qt/5.12.3/gcc_64/lib/libQt5Core.so.5 (0x00007f6cfbbd9000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6cfb850000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6cfb638000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6cfb247000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6cfb028000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f6cfae0b000)
libicui18n.so.56 => /home/dan/Qt/5.12.3/gcc_64/lib/libicui18n.so.56 (0x00007f6cfa972000)
libicuuc.so.56 => /home/dan/Qt/5.12.3/gcc_64/lib/libicuuc.so.56 (0x00007f6cfa5ba000)
libicudata.so.56 => /home/dan/Qt/5.12.3/gcc_64/lib/libicudata.so.56 (0x00007f6cf8bd7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6cf89d3000)
libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f6cf87d1000)
libglib-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f6cf84ba000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6cf811c000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6cfc56f000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f6cf7eaa000)
ldconfig -p | grep libQt5Core
libQt5Core.so.5 (libc6,x86-64, OS ABI: Linux 2.6.28) => /home/dan/Qt/5.12.3/gcc_64/lib/libQt5Core.so.5
libQt5Core.so.5 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
libQt5Core.so (libc6,x86-64, OS ABI: Linux 2.6.28) => /home/dan/Qt/5.12.3/gcc_64/lib/libQt5Core.so
Cmake output:
Running /home/dan/Qt/Tools/CMake/bin/cmake -S /home/dan/records/projects/qt_learning/first_demo/demo2/demo2 -B /home/dan/records/projects/qt_learning/first_demo/demo2/build-demo2-Desktop_Qt_5_12_3_GCC_64bit-Debug in /home/dan/records/projects/qt_learning/first_demo/demo2/build-demo2-Desktop_Qt_5_12_3_GCC_64bit-Debug.
-- Configuring done
********** Qt5Core_DIR /home/dan/Qt/5.12.3/gcc_64/lib/cmake/Qt5Core
********** CMAKE_EXE_LINKER_FLAGS
********** CMAKE_EXE_LINKER_FLAGS -Xlinker -v -v
-- Generating done
-- Build files have been written to: /home/dan/records/projects/qt_learning/first_demo/demo2/build-demo2-Desktop_Qt_5_12_3_GCC_64bit-Debug
Elapsed time: 00:00.
Compiler output:
13:36:35: Running steps for project demo2...
13:36:35: Starting: "/home/dan/Qt/Tools/CMake/bin/cmake" --build . --target all
[1/4 24.5/sec] Automatic MOC and UIC for target demo2
[2/4 26.0/sec] Building CXX object CMakeFiles/demo2.dir/demo2_autogen/mocs_compilation.cpp.o
[3/4 2.5/sec] Building CXX object CMakeFiles/demo2.dir/main.cpp.o
[4/4 2.8/sec] Linking CXX executable demo2
Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04)
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/7/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/7/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-g' '-v' '-o' 'demo2' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/7/collect2 -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccNlMLa9.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o demo2 /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. -v CMakeFiles/demo2.dir/demo2_autogen/mocs_compilation.cpp.o CMakeFiles/demo2.dir/main.cpp.o -rpath /home/dan/Qt/5.12.3/gcc_64/lib /home/dan/Qt/5.12.3/gcc_64/lib/libQt5Core.so.5.12.3 -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
collect2 version 7.5.0
/usr/bin/ld -plugin /usr/lib/gcc/x86_64-linux-gnu/7/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper -plugin-opt=-fresolution=/tmp/ccNlMLa9.res -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id --eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed -dynamic-linker /lib64/ld-linux-x86-64.so.2 -pie -z now -z relro -o demo2 /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/Scrt1.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/7/crtbeginS.o -L/usr/lib/gcc/x86_64-linux-gnu/7 -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/7/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/7/../../.. -v CMakeFiles/demo2.dir/demo2_autogen/mocs_compilation.cpp.o CMakeFiles/demo2.dir/main.cpp.o -rpath /home/dan/Qt/5.12.3/gcc_64/lib /home/dan/Qt/5.12.3/gcc_64/lib/libQt5Core.so.5.12.3 -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/lib/gcc/x86_64-linux-gnu/7/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/crtn.o
GNU ld (GNU Binutils for Ubuntu) 2.30
COLLECT_GCC_OPTIONS='-g' '-v' '-o' 'demo2' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
13:36:36: The process "/home/dan/Qt/Tools/CMake/bin/cmake" exited normally.
13:36:36: Elapsed time: 00:01.
Any assistance would be greatly appreciated.
You can add message("Qt5Core_DIR ${Qt5Core_DIR}") to CMakeLists.txt after find_package to check if find_package found Qt in /home/dan (not sure that it should - you probably need to add PATHS argument to help find_package). Or check this value in CMakeCache.txt.
Also you can add -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON to cmake arguments to enable verbose build to check what linker does.

QBS: qbs fails to run moc when class is declared through a macro in another file

In my project I need to create QObject derived classes (with Q_OBJECT and signals) using a macro. The macro resides in a separate file. Here is a simplified example:
The macro is declared in the file CreateQtClass.h:
#ifndef __CREATEQTCLASS_H__
#define __CREATEQTCLASS_H__
#define CREATE_QT_CLASS( ClassName ) \
class ClassName : public QObject \
{ \
Q_OBJECT \
\
signals: \
Q_SIGNAL void mySignal( void ); \
};
#endif //__CREATEQTCLASS_H__
I use the macro to create my class in the file MyQtClass.h
#ifndef __MYQTCLASS_H__
#define __MYQTCLASS_H__
#include <QObject>
#include "CreateQtClass.h"
CREATE_QT_CLASS( MyQtClass );
#endif //__MYQTCLASS_H__
In my .qbs file, I add MyQtClass.h to the files property, like this:
import qbs
QtApplication {
name: "HelloWorld-Qt"
files: [ "main.cpp", "MyQtClass.h" ]
}
Now, when running qbs build, qbs doesn't run 'moc' on MyQtClass.h. It looks like it doesn't do the scanning correctly, and doesn't detect the Q_OBJECT inside the macro.
(I may note that if the macro declaration and usage are in the same file, everything works fine).
My question:
Is there a way for the user to manually force qbs to run 'moc' on a file?
Maybe we need something like a "force_moc" fileTag (the opposite of "unmocable") which I can apply to a group containing MyQtClass.h.
Addition:
I am adding a simple Makefile and main.cpp to demonstrate that moc works well with the above approach:
The file main.cpp:
#include <QDebug>
#include "MyQtClass.h"
static void mySlot( void )
{
qDebug() << "Hello slot";
}
int main( void )
{
MyQtClass c;
QObject::connect( &c, &MyQtClass::mySignal, &mySlot );
emit c.mySignal();
return 0;
}
The Makefile:
CXX = /usr/bin/g++
MOC = /home/user/programs/Qt5.11.2/5.11.2/gcc_64/bin/moc
INCLUDES = \
-I/home/user/programs/Qt5.11.2/5.11.2/gcc_64/include \
-I/home/user/programs/Qt5.11.2/5.11.2/gcc_64/include/QtCore \
-I/home/user/programs/Qt5.11.2/5.11.2/gcc_64/mkspecs/linux-g++ \
-I/usr/include
LINK_FLAGS = \
-Wl,-m,elf_x86_64,-rpath,/home/user/programs/Qt5.11.2/5.11.2/gcc_64/lib \
-L/home/user/programs/Qt5.11.2/5.11.2/gcc_64/lib \
-m64 /home/user/programs/Qt5.11.2/5.11.2/gcc_64/lib/libQt5Core.so.5.11.2 \
-lpthread
C_FLAGS = \
-g \
-O0 \
-Wall \
-Wextra \
-m64 \
-pipe \
-fexceptions \
-fvisibility=default \
-fPIC \
-DQT_CORE_LIB \
$(INCLUDES) \
-std=c++11
SOURCES = main.cpp
OBJS = $(SOURCES:%.cpp=%.cpp.o)
HEADERS_THAT_NEED_MOC = MyQtClass.h
MOC_OBJS = $(HEADERS_THAT_NEED_MOC:%.h=moc_%.cpp.o)
all: HelloWorld-Qt
HelloWorld-Qt: $(OBJS) $(MOC_OBJS)
$(CXX) $^ $(LINK_FLAGS) -o $#
%.cpp.o : %.cpp
$(CXX) $(C_FLAGS) -c $^ -o $#
moc_%.cpp: %.h
$(MOC) -DQT_CORE_LIB $(INCLUDES) $^ -o $#
clean:
rm -f *.cpp.o HelloWorld-Qt moc_*.cpp
I don't think your approach can work, independent of the build tool you use. Keep in mind that moc looks for the Q_OBJECT macro. No such macro can ever be found in MyQtClass.h, because neither moc nor the build tool supporting it will expand the CREATE_QT_CLASS macro, because macro expansion would also expand away Q_OBJECT.
Note that if you add CreateQtClass.h to your qbs file, you will notice that qbs does run moc -- but on the CreateQtClass file. That's the correct behavior, because that's where the Q_OBJECT macro occurs.
I double-checked with qmake and cmake, and they all behave the same way: If you do not list CreateQtClass in the project file, they will not run moc. If you do list it, moc is run on that file.
If you want to keep using your macro, you'll have to make sure to reference Q_OBJECT at the calling site, e.g. as a macro parameter. But even then, I'm not sure moc itself will be fond of that construct.

QT EGLFS not showing Text

I am having trouble getting the QT EGLFS platform to show text with the basic UI controls... Any idea what I might be missing?
Here is the code:
/*
// Shows text:
sudo Xorg &
clang++-3.8 -g --std=c++11 -fPIC -Wall \
-I /usr/include/x86_64-linux-gnu/qt5/ \
test1.cpp \
-l Qt5Core \
-l Qt5Gui \
-l Qt5Widgets \
-o test1 &&
sudo DISPLAY=:0 HOME=/tmp ./test1
sudo killall Xorg
// Does not show text:
clang++-3.8 -g --std=c++11 -fPIC -Wall \
-I /usr/include/x86_64-linux-gnu/qt5/ \
test1.cpp \
-l Qt5Core \
-l Qt5Gui \
-l Qt5Widgets \
-o test1 &&
sudo HOME=/tmp ./test1 --platform eglfs
*/
#include <QtWidgets/QApplication>
#include <QtWidgets/QOpenGLWidget>
#include <QtWidgets/QLabel>
#include <QtWidgets/QTextEdit>
#include <QtWidgets/QPushButton>
int main(int argc, char *argv[]) {
QApplication* app = new QApplication(argc, argv);
QOpenGLWidget root_widget;
root_widget.setAutoFillBackground(true);
root_widget.show();
QTextEdit text_box1(&root_widget);
text_box1.setPlainText("INITIAL TEXT");
text_box1.setGeometry(0, 0, 500, 50);
text_box1.show();
QPushButton button1(&root_widget);
button1.setGeometry(0, 60, 500, 50);
button1.setText("Test1");
button1.show();
return app->exec();
}
When I just use Xorg I get this (the text shows up as expected):
But if I use EGLFS, this is what I get (No text):
EDIT:
I am on Ubuntu Desktop 16.04, I am using qt5 as packaged by ubuntu, Ubuntu reports package version: 5.5.1+dfsg-16ubuntu7.1

Opencv2 cvtColor() does not work

I am using OpenCV2 on Ubuntu 12.04. I can successfully run image read-display codes.
However I am not able to run codes with inbuilt functions eg. cvtColor()
#include <opencv2/core/core.hpp>
#include <opencv2/highgui/highgui.hpp>
#include <stdio.h>
int main(int argc, char *argv[])
{
cv::Mat image = cv::imread("img.jpg");
if( image.data == NULL )
{
printf( "file cannot be loaded\n");
return 1;
}
cv::namedWindow("My");
cv::imshow("My", image);
cv::Mat result;
cv::cvtColor(image, result, CV_BGR2Luv);
cv::imwrite("outImg.jpg", result);
cv::waitKey(0);
return 0;
}
I am using Qt-creator for my OpenCV
After compiling with --libs, --cflags I get following compiler error:
make: Entering directory `/home/swaroop/Work/ai-junkies/cuda/uc_davis/opencv2.x/OpenCV2Test'
g++ -g -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_WEBKIT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4 -I/usr/include/opencv -I. -o main.o main.cpp
main.cpp: In function 'int main(int, char**)':
main.cpp:22:29: error: 'CV_BGR2Luv' was not declared in this scope
main.cpp:22:39: error: 'cvtColor' was not declared in this scope
Please help me fix this.
cvtColor declared in opencv2/imgproc/imgproc.hpp
keep in mind it's #include not #import
#include <opencv2/imgproc/imgproc.hpp>
Alternatively, if you are testing things and not concerned with overdoing the includes, you can simply have one line:
#include <opencv2/opencv.hpp>
and it will include most opencv2 headers.

UNIX symbol referencing error

Greetings Everyone.
I'm currently trying to compile a multiple-language program (C, C++ and FORTRAN) using GNU compilers in UNIX (g++, gcc & f77 respectively).
All my sources are compiling into objects with no errors however I encounter a symbol referencing error as they are linked as shown below:
f77 -L/usr/sfw/lib -R/usr/sfw/lib -lgcc_s -o SlowDynamic.exe main.o \
SA.o mersenne.o CFE.o MA_57.o blas.o MA_57_Depend.o Metis.o\
BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o
NOTICE: Invoking /usr/bin/f90 -f77 -ftrap=%none -L/usr/sfw/lib -R/usr/sfw/lib -lgcc_s -o SlowDynamic.exe main.o SA.o mersenne.o CFE.o MA_57.o blas.o MA_57_Depend.o Metis.o BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o
Undefined first referenced
symbol in file
_Znwj SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEED1Ev SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEEC1Ev SA.o
_ZNKSsixEj main.o
_ZNSolsEPFRSoS_E SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEE4openEPKcSt13_Ios_Openmode SA.o
_ZNSolsEd SA.o
_ZNSolsEi SA.o
__cxa_end_catch SA.o
__cxa_begin_catch SA.o
_ZdlPv SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEE7is_openEv SA.o
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_c SA.o
_ZSt4cerr SA.o
_ZSt4cout SA.o
_ZNSt14basic_ofstreamIcSt11char_traitsIcEE5closeEv SA.o
_ZNSt8ios_base4InitD1Ev main.o
_ZNSt8ios_base4InitC1Ev main.o
_ZNKSt9basic_iosIcSt11char_traitsIcEEntEv SA.o
__gxx_personality_v0 main.o
_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc SA.o
__cxa_rethrow SA.o
_ZNKSs4sizeEv main.o
_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_ SA.o
ld: fatal: Symbol referencing errors. No output written to SlowDynamic.exe
*** Error code 1
make: Fatal error: Command failed for target `SlowDynamic.exe'
With the Following Makefile:
products: SlowDynamic.exe
SlowDynamic.exe: main.o SA.o mersenne.o CFE.o BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o MA_57.o blas.o MA_57_Depend.o Metis.o
f77 -L/usr/sfw/lib -R/usr/sfw/lib -lgcc_s -o SlowDynamic.exe main.o \
SA.o mersenne.o CFE.o MA_57.o blas.o MA_57_Depend.o Metis.o\
BCs.o EMatrix.o Numbering.o KMatrix.o Solve.o
main.o: main.cpp
g++ -c -o main.o main.cpp
SA.o: SA.cpp
g++ -c -o SA.o SA.cpp
mersenne.o: mersenne.cpp
g++ -c -o mersenne.o mersenne.cpp
CFE.o: CFE.c
gcc -c -o CFE.o CFE.c
MA_57.o: MA_57.f
f77 -c -o MA_57.o MA_57.f
blas.o: blas.f
f77 -c -o blas.o blas.f
MA_57_Depend.o: MA_57_Depend.f
f77 -c -o MA_57_Depend.o MA_57_Depend.f
Metis.o: Metis.f
f77 -c -o Metis.o Metis.f
BCs.o: BCs.c
gcc -c -o BCs.o BCs.c
EMatrix.o: EMatrix.c
gcc -c -o EMatrix.o EMatrix.c
Numbering.o: Numbering.c
gcc -c -o Numbering.o Numbering.c
KMatrix.o: KMatrix.c
gcc -c -o KMatrix.o KMatrix.c
Solve.o : Solve.c
gcc -c -o Solve.o Solve.c
clean:
rm *.o Main.exe *.gpi
I have read that this is typically the fault of missing libraries. I know the C & FORTRAN code compiles fine seperatly (respective libraries included) as does the C++ code when compiled on its own. This leads me to believe that it is the interface between the two programs that causes the error. Unfortunatly I've little to no experiance debugging this sort of problem and without any clues from the linker its hard to move forward. I'll include the necessary parts of my program that deal with the interface between the two sides of the program.
First the C++ part: SA.h, SA.cpp
SA.h:
class SimAnneal {
...
std::vector<float> DensityArray;
std::vector<float> EnergyArray;
public
double ObjFunction ();
...
}
SA.ccp:
#include <math.h>
#include <iostream>
#include <fstream>
#include <time.h>
#include <vector>
#include "SA.h"
#include "CFE.h"
#include "randomc.h" //Includes mersenne.cpp
double SimAnneal::ObjFunction ()
{
CFE(&DensityArray[0], &EnergyArray[0]);
// sends pointers of both arrays to CFE.c and modifies EnergyArray as
// shown in CFE.c
double SumStrainEnergy = 0;
for (int i = 0; i < EnergyArray.size(); i++)
{
SumStrainEnergy += EnergyArray[i]; //Effectively sum of array
//engy[] from CFE.c
}
return SumStrainEnergy;
}
Secondly the C/FORTRAN part: CFE.h, CFE.c
CFE.h:
#ifdef __cplusplus
extern "C" {
#endif
void CFE(float density[], float energy[]);
#ifdef __cplusplus
}
#endif
CFE.c:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <math.h>
#include "BCs.h"
#include "EMatrix.h"
#include "Numbering.h"
#include "KMatrix.h"
#include "fg_types.h"
#include "Solve.h"
void CFE(float density[], float energy[])
{
...stuff...
float * dens;
dens = density; //pass pointer of array density[0] in SA.cpp to CFE.c
...more stuff....
float * engy;
engy = energy; //pass pointer of array energy[0] in SA.cpp to CFE.c
***Modify engy in some respects****
}
Essentially the ObjFunction in SA.cpp is called in main.cpp, which contains main().
Is there any visible fault?
Is there any way I can ask the linker to announce what causes / where the error occours in the linking?
Any help will be much appriciated.
Thank you.
+++ EDIT: Verbose feedback +++
birch $ g++ -v Hello.cpp
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
/usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/cc1plus -quiet -v Hello.cpp -quiet -dumpbase Hello.cpp -mcpu=v7 -auxbase Hello -version -o /var/tmp//cc2JwHRb.s
ignoring nonexistent directory "/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../sparc-sun-solaris2.10/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/sparc-sun-solaris2.10
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../include/c++/3.4.3/backward
/usr/local/include
/usr/sfw/include
/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/include
/usr/include
End of search list.
GNU C++ version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) (sparc-sun-solaris2.10)
compiled by GNU C version 3.4.3 (csl-sol210-3_4-branch+sol_rpath).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Hello.cpp:6:2: warning: no newline at end of file
/usr/ccs/bin/as -V -Qy -s -xarch=v8 -o /var/tmp//ccvAshv7.o /var/tmp//cc2JwHRb.s
/usr/ccs/bin/as: Sun Compiler Common 10 Patch 09/04/2007
/usr/sfw/libexec/gcc/sparc-sun-solaris2.10/3.4.3/collect2 -V -R/usr/sfw/lib -Y P,/usr/ccs/lib:/usr/lib -Qy /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crt1.o /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crti.o /usr/ccs/lib/values-Xa.o /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crtbegin.o -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3 -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../../../sparc-sun-solaris2.10/lib -L/usr/ccs/lib -L/usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/../../.. /var/tmp//ccvAshv7.o -lstdc++ -lm -R/usr/sfw/lib -lgcc_s -lgcc -lc -R/usr/sfw/lib -lgcc_s -lgcc -lc /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crtend.o /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/crtn.o
ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.490
Some of those undefined symbols clearly relate to standard C++ classes (i.e. ostream).
You need to ensure that you've got at least the C++ library linked (-lstdc++).
To debug further:
Run f77, g++, etc, in verbose mode (-v) with single language programs and see which libraries the compiler automatically includes in the link phase for each language
For symbols that are in your own code, use nm to look at both the native language declarations and non-native invocations to determine how they mismatch. There are rules about underscore prefixes, etc, which are commonly applied.
(As far as I can remember, but it's 15 years since I last linked C and Fortran, C symbols are always internally prefixed with an underscore, but Fortran symbols are not).
The main problem is that you're doing the linking step with the F77 compiler, which doesn't link in the C++ standard library by default. Like Alnitak said, specify -lg++ explicitly during linking to get it.
Also, if you are calling C++ functions from C code (or from F77 code), make sure you enclose the prototypes of those functions in an extern "C" {} block so that their symbol names show up in the standardized C form, rather than the mangled C++ form (this restricts you from some things, though, such as overloading). See here for more information.
Usually, you should link a program containing any C++ code with the C++ compiler, adding the Fortran and C libraries to the link line. Further, the standard advice is to make the main() program C++, nor Fortran, since the startup sequences for C++ are different. Make the Fortran code into a function that you call from a minimal C++ main.
int main(void) // Assuming no argument handling - probably incorrect
{
return(fortran_main_program());
}

Resources