I have a c program, that if I build it in the shell with this command:
gcc -o simpledemo -fpic -fsigned-char -DPLATFORM_LINUX -Iinclude/ simpledemo.c ../AcapelaLibs/libbabile.a -lstdc++
it compiles, runs, and produces the expected output.
gcc info:
/usr/bin/gcc
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
However, if I compile it with Qt Creator (Qt 5.5.1), it compiles and runs but a NULL value is returned from a function of the library I use.
Qt uses the following g++:
/usr/bin/g++
g++ (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
I think it might be something with the compiler flags. This is what I'm doing in Qt to match the shell command:
in .pro file:
QMAKE_CXXFLAGS += -DPLATFORM_LINUX
INCLUDEPATH += $$PWD/include/
I think the INCLUDEPATH is OK because I can access files there from within my code (they are recognizable).
And note that in the shell compilation I use a library ../AcapelaLibs/libbabile.a, so in Qt I click Add Library... and choose that same library, and Qt adds it to the .pro file. Also here I can access library functions from within my code.
The problem is that a function from libbabile.a returns NULL if I compile and run from Qt (or compile in Qt and run from shell).
What's the difference between the 2 methods that makes one of them succeed and the other fail?
Library function behaves differently if compiled in Qt Creator. I
think it might be something with the compiler flags.
What compiler flags are different from used in command line?
You can examine Qt Creator compiler output and get all the compiler options specified from there. Then you can compare those with expected set of options and deliberately add or remove those options in your project .pro file:
# C++ flags
QMAKE_CXXFLAGS += -opt1 -opt2 # add
QMAKE_CXXFLAGS -= -opt1 -opt2 # remove
QMAKE_CXXFLAGS_RELEASE += -opt1 -opt2 # add
QMAKE_CXXFLAGS_RELEASE -= -opt1 -opt2 # remove
QMAKE_CXXFLAGS_DEBUG += -opt1 -opt2 # add
QMAKE_CXXFLAGS_DEBUG -= -opt1 -opt2 # remove
# C flags, slightly different macro
QMAKE_CFLAGS += -opt1 -opt2 # mind add/remove/debug/release
For both debug and release modes and separately.
Related
I used Qt 5.7 and gcc 4.9.2. Qt Core module throw Qt requires C++11 support error.
This page say that
gcc 4.9.2 fails to compile Qt.
So I installed gcc 4.8. I check using below command on terminal :
$ g++ --version
g++ (Ubuntu 4.8.4-1ubuntu15) 4.8.4
My kit uses cmake not qmake. I add TARGET_LINK_LIBRARIES ( xxxx yyyy /usr/bin/c++ -std=c++11 to CMakeLists-txt.
I restart my pc and run my application again. Same error is throwed.
/opt/Qt/5.7/gcc_64/include/QtCore/qbasicatomic.h:61: error: #error "Qt requires C++11 support"
# error "Qt requires C++11 support"
^
How can I solve it?
If using QtCreator, you can add this to your .pro file:
CONFIG += c++11
https://wiki.qt.io/How_to_use_C%2B%2B11_in_your_Qt_Projects
Its has been a while.
How I finally solve it is indicating in CMakeLists.txt the following line just after project(MyProject):
add_compile_options(-std=c++11)
That says to cmake, to create a Makefile that will use c++11 solving issues.
solution for me was (in your .pro file):
QMAKE_CXXFLAGS += -stdlib=libc++
QMAKE_CXXFLAGS += -std=c++11
QMAKE_CXXFLAGS += -mmacosx-version-min=10.7
QMAKE_LFLAGS += -mmacosx-version-min=10.7
Turn c++11 on explicitly:
set(CMAKE_CXX_FLAGS "-std=c++11" CACHE STRING "compile flags" FORCE) after project(...) declaration.
add_library(MyLib SHARED ${PROJECT_HEADERS} ${PROJECT_SOURCES})
...
set_property(TARGET MyLib PROPERTY CXX_STANDARD 11)
set_property(TARGET MyLib PROPERTY CXX_STANDARD_REQUIRED ON)
SOMETIMES, this will not be a configuration issue as mentioned in other answers. In my case, the problem was one file that happened to have been saved with a .CPP extension rather than .cpp. QMake (Qt5) was misidentifying the file and trying to compile it with the C compiler rather than the C++ compiler. The QMake from Qt4 was not exhibiting this issue. Renaming the file fixed the issue.
My comment at the time was "Could this really be that f&%%& simple!!"
I am compiling dlib 18.18 on Windows 10 for QT 5.6 with MinGW 4.9.2.
I have read all recommendations (http://dlib.net/faq.html#Whyisdlibslow): AVX or SSE4 instructions, Release mode.
The example "webcam_face_pose_ex.exe" works like a charm and really fast.
The problem:
But when I use the frontal_face_detector under QT the framerate is really low.
640x480 ~170 ms
1920x1080 ~1100 ms
System configuration: Windows 10 (x64), Intel Core i5-3550, QT 5.6, OpenCV 3.1.0, MinGW 4.9.2
Tried all variations of using AVX/SSE4 instructions in dlib and opencv.
But I think that it's something different - since the example is fast.
Code used in QT is copy-pasted from the example as well, even without the GUI.
In Debug mode 640x480 frames take 6-7 seconds to process.
.pro file dump:
DIR_DLIB = "$${LIBSDIR}dlib/dlib18.18/"
DEFINES += DLIB_ENABLE_ASSERTS
LIBS += -luser32 -lws2_32 -lgdi32 -lcomctl32 -limm32 -lwinmm
INCLUDEPATH += "$${DIR_DLIB}include"
DEPENDPATH += "$${DIR_DLIB}include"
LIBS += -L"$${DIR_DLIB}lib"
LIBS += -ldlib
Dlib face detector is header-based and does not depend on the compiler flags used to compile dlib.lib itself.
Dlib has a documented option "-DUSE_AVX_INSTRUCTIONS=ON", but it will not work if you are not building with CMAKE and including dlib/cmake file into your CMakeLists.txt
You should add AVX enabling flags for compiler into your project to make it work fast
The solution is to add an explicit parameter to your .pro file:
QMAKE_CXXFLAGS_RELEASE += -mavx
When you are compiling project in Qt Creator, you can see how does it call compiler and what flags are used. Ensure you have -mavx flag. -msse2 will work about 20% slower
I want to have certain variables defined when I am compiling my program with QtCreator versus our build system for an embedded Linux application. This would do things like turn on debugging I've been looking at the docs here: http://qt-project.org/doc/qt-4.8/qmake-variable-reference.html, but have not found a solution. Ideally I'd like something like this:
ide {
# Build release version
# CONFIG+=debug
# CONFIG+=declarative_debug
CONFIG+=release
## Optimize flags
QMAKE_CXXFLAGS_RELEASE += -O3
QMAKE_CXXFLAGS_DEBUG += -O3
QMAKE_LFLAGS += -O3
}
in the project tab in QtCreator you can specify a custom environment variable that will be used for the build
with $$(VAR) you can query it during qmake and
ide = $$(IDE)
contains(ide, qtcreator){
CONFIG+=debug
}else{
# Build release version
# CONFIG+=debug
# CONFIG+=declarative_debug
CONFIG+=release
## Optimize flags
QMAKE_CXXFLAGS_RELEASE += -O3
QMAKE_CXXFLAGS_DEBUG += -O3
QMAKE_LFLAGS += -O3
}
I want to provide options to the linker when building a static library using qmake. Say I'd want to get verbose linker output when building with MSVC. The project file looks as follows:
# mylib.pro
TEMPLATE = lib
TARGET = mylib
CONFIG += staticlib
QT += core
win32-msvc*: QMAKE_LFLAGS += /VERBOSE
unix: QMAKE_LFLAGS += -v
That's the entire project file. It should result in an empty static library with no objects in it.
Setting neither QMAKE_LFLAGS nor QMAKE_LFLAGS_STATIC_LIB nor LIBS has any effect on the linker. Nothing set in those variables even makes it to the Makefile. If QMAKE_LFLAGS worked, I'd expect to see /VERBOSE or -v passed to the linker on the command line, as appropriate for given platform.
It doesn't matter what makefile generator is used, this behavior seems to be consistent. The two platforms of interest are.
qmake -spec win32-msvc2008
qmake -spec macx-llvm
Due to cross-platform nature of qmake, you can test it on any platform where you happen to have Qt installed. This reproduces on qmake from both Qt 4.8.4 and 5.1.1. The msvc version given in the mkspec doesn't matter.
In staticlib projects, the LFLAGS are not passed to the linker. In fact, there's no documented way to pass such flags.
The solution is generator-dependent.
For msvc_nmake, LIBFLAGS are passed to the linker instead. To get verbose output, you might add
QMAKE_LIBFLAGS += /VERBOSE
To verify that it works, on any system, you can invoke qmake -spec win32-msvc2008; the particular msvc version doesn't matter.
For unixmake, AR is used to invoke the linker, so you have to add the flags to QMAKE_AR. To get verbose output, you might add
QMAKE_AR += -v
To verify, invoke qmake -spec macx-llvm; any other unix spec should work as well.
I work on Mac OS 10.8.5 and Qt 5.1.1 with among other things, qdebug class which work well with some projects and doesn't compile with some others. I've already tried to re-install Qt which didn't change a thing.
It is certainly due to the use of SDL library (?!) but it used to work fine. Here's a part of the compilation output :
In file included from ../../Stage/Joker/tests/SDLTest/main.cpp:7:
In file included from /Applications/QT/5.1.1/clang_64/include/QtCore/QDebug:1:
In file included from /Applications/QT/5.1.1/clang_64/include/QtCore/qdebug.h:46:
In file included from /Library/Frameworks/QtCore.framework/Headers/qhash.h:46:
/Library/Frameworks/QtCore.framework/Headers/qchar.h:76:5: error: unknown type name 'QT_ASCII_CAST_WARN_CONSTRUCTOR'
QT_ASCII_CAST_WARN_CONSTRUCTOR QChar(char c);
^
If needed, I can provide more output or unworking Qt classes.
I build my code with Qt => Build => Run
Unfortunatly, I'm unable to reproduce the code on an other computer.
Here's the pro file (which work well with all my co-workers, except me) :
TEMPLATE = app
SOURCES += main.cpp
OBJECTIVE_HEADERS += ../../libs/PhGraphic/SDLMain.h
OBJECTIVE_SOURCES += ../../libs/PhGraphic/SDLMain.m
LIBS += -framework Cocoa
QMAKE_CXXFLAGS += -F/Library/Frameworks
QMAKE_OBJECTIVE_CFLAGS += -F/Library/Frameworks
LIBS += -F/Library/Frameworks
LIBS += -framework SDL -framework SDL_image -framework SDL_ttf
I'd once had this problem after installing a software: it created a QtCore.framework in the /Library/Framework folder that overrided the QtCore of your current Qt kit (due to QMAKE_CXXFLAGS += -F/Library/Frameworks).
It's qDebug, and there are two overloads:
a stream-returning function
qDebug() << "foo";
a printf-style function
qDebug("foo");
You need to provide a minimum reproducible test case for us to help you.
How are you building your code? Are you using qmake to produce the Makefile? We'd need to see the .pro file at the minimum, and please minimize it by removing useless boilerplate comments etc.