I would like to include libQtGui.so.4 libQtNetwork.so.4 and libQtCore.so.4 in the same directory as where my app resides. How would I make Qt understand this? y purpose is to have a standalone app that uses shared libraries
Setting the LD_LIBRARY_PATH environment variable is one option. For example:
export LD_LIBRARY_PATH=/path/to/dir/with/libs:$LD_LIBRARY_PATH
Another option is to set the RPATH of your Qt application during linking. Setting the RPATH to the value "$ORIGIN" will cause the dynamic linker to look in the same directory as your Qt application at runtime. For example, if using qmake, add the following snippet to your project file:
unix:!mac{
QMAKE_LFLAGS += -Wl,--rpath=\\\$\$ORIGIN
QMAKE_LFLAGS += -Wl,--rpath=\\\$\$ORIGIN/lib
QMAKE_LFLAGS += -Wl,--rpath=\\\$\$ORIGIN/libs
QMAKE_RPATH=
}
This will set the RPATH to "$ORIGIN:$ORIGIN/lib:$ORIGIN/libs", meaning that the dynamic linker will first look in the location of your Qt application, then in a lib subdirectory at its location, then in a libs subdirectory at its location, and finally in any system defined locations.
UNIX / Linux is going to look in LD_LIBRARY_PATH (if set) first before looking in the system standard libs. So if you set that, you can indeed override. Just like setting the PATH on Windows. Same effect. The ordering matters.
You can add ./ or . to LD_LIBRARY_PATH as well.
export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH
LD_LIBRARY_PATH and QMAKE_RPATH never worked for me. Instead, I set QMAKE_RPATHDIR in my .pro file. For example after having built and installed (make install) Qt, it has been placed in /usr/local/Trolltech/Qt-4.8.5/lib/. I then write the following in my .pro file:
QMAKE_RPATHDIR += /usr/local/Trolltech/Qt-4.8.5/lib/
Note 1: Relative paths seem not to work. Prefer absolute paths.
Note 2: When you then make, you can see that the following option is given to the linker: -Wl,-rpath,/usr/local/Trolltech/Qt-4.8.5/lib/
Note 3: To be sure that the binary links dynamically to the correct library, you can display the version of Qt at runtime delivered by qVersion().
Related
I have a project setup with a couple of Apps with a shared library, this is all built nicely using a SUBDIRS project, where the apps depend on the shared library.
TEMPLATE = subdirs
SUBDIRS = app1 app2 sharedLib
app1.depends = sharedLib
app2.depends = sharedLib
Each app also contains a number of tests, with CONFIG += testcase set.
This creates a check target so we can run all unit test from the top level .pro using make check.
The problem is that some of the app tests require the presence of the code within the sharedLib, therefore it needs to be discoverable according to each platforms library lookup rules.
On Windows one option is to have the sharedLib location on the PATH, on linux we can add the sharedLib location to LD_LIBRARY_PATH, on mac DYLD_LIBRARY_PATH.
One solution is to just set the location of the built shared lib before running make check:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:build/sharedDll/
make check
and this works, but it seems a little redundant as it is the build scripts themselves that are building the shared library so they know the path to the sharedLib binary location, which can be referenced from within .pro/pri files at:
$$TOP_BUILDDIR/sharedLib/release
So, is there anyway to set the PATH/LD_LIBRARY_PATH/DYLD_LIBRARY_PATH from within the project files for the purposes of the make check command?
If you are using gcc, you can use rpath parameter of gcc.
-rpath=dir
Add a directory to the runtime library search path. This is used
when linking an ELF executable with shared objects. All -rpath
arguments are concatenated and passed to the runtime linker, which
uses them to locate shared objects at runtime.
QMAKE_CXXFLAGS += -rpath=/the/absolute/path
If you use that technique, it will not be necessary to edit LD_LIBRARY_PATH
In Qt 5.5, the following qmake statement prepends the path $$TOP_BUILDDIR/sharedLib/release to LD_LIBRARY_PATH for the target check:
check.commands = LD_LIBRARY_PATH=$$TOP_BUILDDIR/sharedLib/release:\$$LD_LIBRARY_PATH $$check.commands
I drew inspiration for this solution from the files testcast.prf and qt_functions.prf (especially the functions qtAddTargetEnv() and qtAddToolEnv()), both located in $$[QT_INSTALL_PREFIX]/mkspecs/features.
I learned that qmake has a variable for searching for libs in a custom dir, it's called QMAKE_LIBDIR.
Instead of manually adding a lib path to LD_LIBRARY_PATH, you can set this in your .pro file, and then link the libraries you need with:
QMAKE_LIBDIR = /path_to_your_libs
-L/path_to_your_libs -l<whatever_lib_you_need>
Question
a) How do we add library paths where the project should look for depended libraries in Qt Creator?
b) How are the settings in project >> Run >> Build Environment related to similar in .pro file? Does the environment variable listed there applies to .pro file as well (well they don't) so what are they exactly?
Context/Details:
Visual Studio has a various environment variables for folders where a project looks for include files, library files or executable files etc. This is rather confusing in Qt Creator and I havne't seen good documentation on it.
The only thing which is obvious is INCLUDEPATHvariable which points to the directories where to look for the include files (.h)
However how do I set the library paths, the path where it should look for dependent libraries/dlls etc? I can specify the exact library with LIBS variable in .pro file, there don't seem to equivalent of LIBPATH variable where it should look for other libraries if not found in current folder.
I have worked around this be adding library path the following way basically using LIBS variable but dropping the library file name and that seems to work and add the path but I don't see this documented anywhere.
LIBS += -L"$$_PRO_FILE_PWD_/Xerces/bin/"
But what makes things more interesting is the settings in Projects >> select 'Run' from current configuration and expand the Run Environment settings.
''
Here there is LIB variable and LIBPATH variable but there are clearly not .pro environment available. It also says here that these settings are local to user and saved in .pro.user file which perhaps suggest it's a different way to set but it doesn't say how to set them in .pro file but it does suggest to set them there if want to apply for all users!
Likewise there are DEPENDPATH AND VPATH and it is not really clearly what they are used for.
I don't have enough Rep to add comments to your question, So am adding my comment in form of answer. I am pretty new to Qt and have been developing Qt GUI application on Linux.
I set this LD_LIBRARY_PATH environment variable with the path to my Qt libraries. Am not sure how much it will be helpful to you since you are using visual studio on windows.
in Projects property go to Build Environment and add a variable with the libs path, example NAME_LIBPATH. So in the .pro file add the following:
# your lib configuration
LIBS += -L$$(NAME_LIBPATH) \
-llibname
I have a QT project which runs on x86 linux and ARM linux embedded (yocto).
For each platform I defined a Kit within QtCreator referencing the appropriate compiler etc.
Now I want to add LIBS to my pro file, but I got different libraries on each platform. I didn't find a way to specify the LIBS-directive dependant on the compiling Kit.
I search something like:
if (Kit == "Desktop")
LIBS += ...
if (Kit == "Embedded Yocto")
LIBS += ...
How to achieve this?
Thank you in advance
I scraped together a solution to the OP's problem by using the answer suggested by #vsz in the comments found here.
I have two kits, one for the local Desktop and one for the Target_ARM device, and I wanted a way to easily build for both of those without having to specially modify the .pro file or anything else. I followed the linked answer and added the following:
In my Desktop kit (for both Debug and Release), I added CONFIG+=Desktop as an additional qmake argument in the qmake build step.
For the Target_ARM kit, I added CONFIG+=Target_ARM in the same spot.
Now, this is where things shifted from the linked answer to the OP's problem. I didn't simply want #defineed variables in my code, I wanted to alter the behavior of qmake based on the selected kit. I don't know if the CONFIG built-in test function supports block designations or not (ie, CONFIG { _several lines here_ }), but it turned out I could copy and paste the CONFIG test function in front of each line that I wanted to be conditional; in fact I could string multiple CONFIGs together, like this:
CONFIG(Desktop, Desktop|Target_ARM):unix:!macx:CONFIG(debug, debug|release): LIBS += /path/to/Desktop/debug/lib
else:CONFIG(Desktop, Desktop|Target_ARM):unix:!macx:CONFIG(release, debug|release): LIBS += /path/to/Destop/release/lib
As it suggests, the above statement will run qmake with the appropriate LIBS path depending on which kit and configuration I have selected. Desktop->debug will generate a Makefile with /path/to/Desktop/debug/lib in it whereas Desktop->release will generate a Makefile with /path/to/Desktop/release/lib. I have similar statements for the Target_ARM kit. Below is an example of selecting the correct INCLUDEPATH: Both tests will evaluate to true when Target_ARM->release is selected.
CONFIG(Target_ARM, Desktop|Target_ARM):CONFIG(release, debug|release): INCLUDEPATH += /include/path/for/Target_ARM/release
In all, I used this method to modify LIBS, INCLUDEPATH, DEPENDPATH, and PRE_TARGETDEPS. I have 4 possible configurations of include paths and libraries depending on which kit I select (Desktop or Target_ARM) and which build configuration I select (build or release). Once this is set up, there is no need to modify the .pro file, simply pick your kit, your build configuration, run qmake, then rebuild.
I don't know off the top of my head where the CONFIG+=Desktop (for example) data is stored, but I would guess in the .pro.user file. So if somebody pulls your .pro file from a repo, they may have to initially configure the project in this manner at least once, but not afterwards (as long as the .pro.user file persists). QT should really have an easy mechanism for doing this front-and-center, especially since one of their selling points is multiple-platform integration. If there's a better way of doing this, I haven't seen it on SO or in the QT documentation yet.
You have all qmake variables here: qt-project.org/doc/qt-4.8/qmake-function-reference.html
You can define a variable
KIT = Desktop
#KIT = EmbeddedYocto
And use contains function
contains( KIT, Desktop ) {
LIBS += ...
}
contains( KIT, EmbeddedYocto ) {
LIBS += ...
}
MY_QT_INSTALL_PREFIX=$$[QT_INSTALL_PREFIX]
equals(MY_QT_INSTALL_PREFIX,"C:/Qt/Qt5.3.1/5.3/msvc2010_opengl"){
message($$[QT_INSTALL_PREFIX])
}
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 want to build qt application that will gather all the necessary binaries for standalone execution on install.
I know that can be done in lines of:
QT_DIR=C:/Qt/4.8.4
dlls_to_move.files += $$DIR/bin/QtCore.dll
however that seems clumsy. Is there a way to retrieve Qt binary folder actually used, like project directory that can be retrieved with $$PWD?
From qmake Advanced Usage:
The special $$[...] operator can be used to access various configuration options that were set when Qt was built:
So I think you'd want to do this in your project file:
dlls_to_move.files += $$[QT_INSTALL_BINS]/QtCore.dll