I am trying to run a program in Qt5.6 with openCV3.1, but no matter what I do, it does not detect openCV include.
Projects -> Build Environment -> Include :
I added C:\opencv\opencv3.1.0\opencv\build\include
Projects -> Build Environment -> LIB:
I added C:\opencv\opencv3.1.0\opencv\build\x64\vc14\lib
However, still in the code there is a yellow line indicating that it doesn't detect opencv:
and there are lots of errors like this:
The environment variable for openCV is also set as:
C:\opencv\opencv3.1.0\opencv\build
How should I install Qt with openCV to avoid these problems?
In the .pro file, add the following lines:
INCLUDEPATH += C:\opencv\opencv3.1.0\opencv\build\include
LIBS += -LC:\opencv\opencv3.1.0\opencv\build\x64\vc14\lib \
opencv310.lib \
And also you need to add the .dll file's path C:\opencv\opencv3.1.0\opencv\build\x64\vc14\bin to the system path (this time you need to restart the Qt IDE)
Related
Qt seems to load openssl dynamically at runtime, as seen in this question.
And apparently, it gets the system openssl. For instance, on macOS, I would rather use the homebrew-installed openssl, and package it into my dmg, so that the users don't need to install it themselves.
How can I tell Qt where to look for the libraries it links? Is there something to do with the qt.conf file?
you can do something like that in your .pro file:
win32-msvc* {
LIBS += -LC:/openssl/lib/ -llibeay32
LIBS += -LC:/openssl/lib/ -lssleay32
INCLUDEPATH += C:/openssl/include
}
left click on your project -> add library -> external library -> choose the .lib file and the include folder for the library. check for which platform it is.
It will put the specific platform dependend commands to your project .pro filefile.
I'm building a project in Qt Creator, and while I don't care where the intermediate .obj files go it's important that the final executable be put in (and run from) a particular directory where the many dependency DLLs etc. are to be found.
So, in Qt Creator, I select the 'Shadow Build' option and specify the path to this directory.
What I always find, however, is that instead of being put into this directory, the final executable is always placed into
the_Directory_I_Actually_Want/debug
... which is no use to me because, when I then try to run or debug the program from within Qt Creator, it won't start because the DLLs that it depends on are all in the_Directory_I_Actually_Want and not in the /debug subdirectory.
I've tried setting DESTDIR within my .pro file to the the_Directory_I_Actually_Want, and I've tried setting TARGET within my .pro file to the_Directory_I_Actually_Want/projectName, and I've tried faddling around with the various options that are part of the 'kit' configuration, and nothing seems to let me have any control over this.
Is there a way of doing this, or am I going to have to change the rest of my build system around just for Qt Creator's benefit?
Three years later...
Just use:
CONFIG -= \
copy_dir_files \
debug_and_release \
debug_and_release_target
On Windows you can use DLLDESTDIR variable which specifies where to copy the target dll or exe. Just add this to your .pro :
CONFIG(release, debug|release): DLLDESTDIR += $$PWD/../exec
On Linux you can use QMAKE_POST_LINK variable which contains the command to execute after linking the TARGET together. So it is like:
CONFIG(release, debug|release): QMAKE_POST_LINK += $$quote(cp project $$PWD/../exec)
Here project is the name of the target file which you provide by TARGET = project
These will copy the executable binary to a directory named exec one level upper than the program working directory. You can have your arbitrary path.
I'm developing an Apache2 module as a subproject of a larger project. The source file is (for example) module_example.c. Apache2 modules are compiled with apxs2, thus:
% apxs2 -c module_example.c
I've successfully added rules (patterned on how ODB works) to my Qt Creator .pro file to find and use apxs2, like this:
APXS_FLAGS =
APXS_FILES += module_example.c
for(dir, APXS_FILES) {
APXS_PWD_FILES += $$PWD/$${dir}
}
apxs.name = apxs2 -c ${QMAKE_FILE_IN}
apxs.input = APXS_PWD_FILES
apxs.output = ${QMAKE_FILE_BASE}.so
apxs.commands = apxs2 $$APXS_FLAGS -c ${QMAKE_FILE_IN}
apxs.depends = $$APXS_PWD_FILES
apxs.clean = module_${QMAKE_FILE_BASE}.so
QMAKE_EXTRA_COMPILERS += apxs
QtCreator correctly compiles the module using apxs2 (although it leaves the binaries in the source directory instead of the build directory, which isn't ideal), but then also tries to compile it with GCC (which fails). How do I tell Qt Creator to use my "extra compiler" instead of the normal one? Changing the extension to something else (module_example.apxs, for example) doesn't appear to be an option, because apxs2 has no option to specify the extension of C source files. Any ideas?
It's not Qt Creator that does it, but qmake. You need to remove module_example.c from SOURCES. The problem is in the part of the .pro file you're not showing.
If you wish to easily access the file from Qt Creator, add it to OTHER_FILES. It will be shown in the project structure in the IDE, but won't be compiled by default.
Also, it's up to you to tell apxs to output to the build path. You need ${OUT_PWD}.
I compiled a library using the MinGW toolchain provided with Qt 5.0.2 on Windows. As a result I received a library.so file. First I failed using the library in a Qt application, but now I found out that everything works fine when I make a copy of the liblibrary.so file and call it liblibrary.dll or liblibrary.lib (which is the only file ending supported by the add library wizard in QtCreator).
Now I wonder if this is normal or if I should change something in order not to have both files (which are exact copies). Leaving one away makes the application crash during start up. I added the library as follows to my Qt pro file:
LIBS += -L"../path/to/library" -llibrary
INCLUDEPATH += $$quote(../path/to/library)
EDIT: I compiled the library using the MinGW of Qt, not as Qt project but using mingw32-make and the provided Makefile. As a result I get the liblibrary.so.
EDIT: It seems to work also when renaming the copy to liblibrary.dll instead of .lib. But still, I need two files to make the application work -- the .so and the .dll.
Chris
That's weird, I think you should get a *.a and *.dll files when building a shared lib with MinGW on Windows, as said in the documentation:
In windows, MinGW will output .a and .dll, MSVC2010 will ouput .lib and .dll. In linux, MinGW will output .so, .so.1, .so.1.0 and .so.1.0.0 – .lib, .a and .so are import libraries.
You definitely shouldn't rename your file!
Be careful to:
not to include the "lib" prefix after "-l" in your project file.
put everything after after "-l" in lower case as you're on Windows
not adding any extension to your library name after "-l"
add and reference the .h file used in your library
A real example using QtWebsocket lib:
INCLUDEPATH += "$${PWD}/include/"
LIBS += -L"$${PWD}/libs/" -lqtwebsocket
...
HEADERS += ... \
$${PWD}/include/QWsSocket.h \
...
In my include/ folder, I have the following file:
QWsSocket.h (taken from original project - required)
In my libs/ folder, I have the following file:
libQtWebsocket.a
QtWebsocket.dll
Edit: I struggled with this too initially. Have you tried to build your lib as a static lib instead (CONFIG += staticlib in your library project)? This might help you getting you *.pro file right before switching to using the shared library.
Edit 2: Ok, the fact that you get a *.so file is still a bit odd. In this question
the user has the same issue as you and keep both files, which is just a workaround. According to a later answer it seems that you need to modify your makefile to generate a file with the proper extension. Maybe this will help: http://www.mingw.org/wiki/sampleDLL
I have a project that uses Qt. So I have "qmake" make my Makefile from the .pro file. But Qmake can also make that .pro file: qmake -project . This worked until I needed to add an external extra library to my project.
I get lots of hits on google that tell me to add LIBS += ... to my project file, but I want to tell qmake -project something that causes it to add it for me. In effect of course I'll be doing it myself, but I don't think that it's proper that I am editing the generated project file.
If for example I add files to the project directory, I'll have to recreate it and add in the library again, or I'll have to manually add the files to the (almost completely computer-generated) project file. I'm now using a script to auto-generate the project file, and then add in the LIBS += directive, but is there a proper way to do this?
When you are developing without the Qt Creator IDE, unless the IDE includes by itself some automatic utilities, you must edit manually the .pro configuration file.
The generated .pro file is a skeleton file which YOU must fill in with the libraries that you need, then the qmake system figures out the other dependencies and compiles your project. It is a essentially a much better version of pkg-config of gtk + Makefiles.
When you add more source and resource files to your project then manually you must add them to the .pro file.
Example:
QT += core gui
TARGET = qtcp1
TEMPLATE = app
SOURCES += main.cpp\
mainwindow.cpp \
miwidget1.cpp \
lcdrange.cpp
HEADERS += mainwindow.h \
miwidget1.h \
lcdrange.h
FORMS += mainwindow.u
Alternately, you can issue qmake -project over and over again, but this can cause some unforseen accidents, since it includes everything that is in the current directory at the time, including the pre-processed files for conversion to standard C++ from QT dialect. This intermediate files must be erased (cleaned), before the remaking the project and the next make or can lead to tricky problems.
Using the official and free QT Creator IDE takes away most of this burden by adding automatically the new data to the .pro file and cleaning loose ends. Some other IDEs like Code::BLocks and Codelite provide some facilities for QT, but not to the level of QT creator. Some prefer to edit the .pro themselves for custom reasons, other like more other styles of IDEs, like Eclipse.
You should test the waters and decide by yourself what fits best to your needs.
ReEdited, to clarify a few things.