I have a .pro file in which I link my libraries using:
LIBS += -L$${OUTDIR} \
-lA \
-lB \
-lC \
I have developed three libraries A, B, C and this is the fourth library I am trying to build, call it D. libD.so needs to link with others. Since I am putting everything under a bin directorty, I added -L$${OUTDIR} there so that it will look for the bin folder for finding libraries. OUTDIR is a variable I set equal to that bin dir and I am sure it is the correct directory. I print it as a message. But I get the error that libD.so can't find libB.so. I am confused here, it finds other A and C, why it can't find B? They are all under the same directory and I am adding that to library path using -L$${OUTDIR}, so. What could be the problem?
By the way, If a delete that -L$${OUTDIR} and instead add that directory directly to LD_LIBRARY_PATH, from QtCreator Projects tab and build configurations, it finds all the libraries correctly.
Remove \ after -lC
LIBS += -L$${OUTDIR} \
-lA \
-lB \
-lC
It can't find it because at the point in the build where it looks for the library, the library isn't built yet. You need to ensure that the libraries are built in the order of their dependencies.
Related
I am trying to compile poky with QT5 for RaspberryPi3.
I found this guide: https://medium.com/#shigmas/yocto-pi-and-qt-e9f2df38a610
However, instead of morty I have decided to use dunfell branch.
I have adjusted the branch names accordingly, same with some renamed/deleted packages and paths.
I have managed to build the image almost flawlessly (QT libraries are installed; example binary - not, but it can be my fault/some compilation flags might have changed between versions; that's another topic).
However, I cannot quite put my finger on how the layers are exactly included:
if I used only bblayers.conf from my layer, bitbake would complain about not seeing raspberrypi3 as a machine definition, not being able to include some files etc.
On the other hand, if I used only bblayers.conf in build directory, then bitbake would complain about not satisfied dependencies in meta-mylayer.
I ended up with duplicating most layer entires, i.e.:
#build/conf/bblayers.conf
BBLAYERS ?= " \
/home/<username>/yoctoproject/poky/meta \
/home/<username>/yoctoproject/poky/meta-poky \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-oe \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-multimedia \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-networking \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-python \
/home/<username>/yoctoproject/poky/meta-raspberrypi \
/home/<username>/yoctoproject/poky/meta-qt5 \
/home/<username>/yoctoproject/meta-mylayer \
"
while meta-mylayer's config looks stunnigly similar
#meta-mylayer/conf/bblayers.conf
BBLAYERS ?= " \
/home/<username>/yoctoproject/poky/meta \
/home/<username>/yoctoproject/poky/meta-poky \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-oe \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-multimedia \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-networking \
/home/<username>/yoctoproject/poky/meta-openembedded/meta-python \
/home/<username>/yoctoproject/poky/meta-raspberrypi \
/home/<username>/yoctoproject/poky/meta-qt5 \
"
Again, as I have previously stated: the whole setup seems to be working reasonably in the end, but nevertheless the layer config I have feels a bit "off", or counter-intuitive to say the least. Which part of the docs have I potentially missed (if any)?
There shouldn't be any bblayers.conf in your layer but there must be a layer.conf file in your meta layer.
You should read the official documentation Understanding and creating layers
Let's talk about it in linux terms. I have a ".so" file. I want to make the executable dependent on it, look for it in the same directory. How do you do it through qmake? Or can this only be achieved through the use of QLibrary?
For example, when you have a ".so" file and want to use it in your project, in qmake you write:
LIBS += -L"path to the folder that contains your .so" -lSoName
But the path is hardcoded, as you can see, and I'm wondering what to write there to make the executable look for the ".so" in the same directory.
You use RPATH
You can configure your binary or library to find shared library (or dll) in current directory using RPATH directive that is emedded in the binary itself which the loader respects at runtime
1- Add the following in your .pro file
unix {
message("Adding RPATH to the app")
QMAKE_LFLAGS += -Wl,-rpath=\'\$$ORIGIN/\'
QMAKE_RPATH =
}
This will set RPATH of executable to current directory and your executable will first try to look for that .so in your current directory and then in standard directory (this process is explained here)
2- After you compile and create binary VERIFY that RPATH is set correctly
objdump -x <path/to/binary> |grep RPATH
it should say $ORIGIN
Compile time configuration:
CXXFLAGS += -L"/path/to/libmarylin.so/file" -lmarylin
There are a few ways to do it.
If the executable is going in the current directory, just do LIBS += -L$$(PWD) -lSoName.
If you're putting the executable into some other sub-directory, specified by some qmake variable like DESTDIR, use LIBS += -L$$(DESTDIR) (or whatever variable holds that directory).
Alternatively, you can add the directory with the executable to the runtime path of the executable, which gives the dynamic linker a list of directories to search for any unresolved libraries at runtime. This can be done with QMAKE_RPATHDIR += -L$$(PWD) and LIBS += -lSoName, which will tell the linker to look for unresolved libraries in the current directory where qmake is run.
Some operating systems may also include the current directory in the runtime search path for libraries by default, in which case just doing LIBS += -lSoName should be sufficient. That is platform-dependent, though, while the above solutions are not.
For a university project we made an OpenGL application which uses Qt for the GUI. When I use qmake -spec macx-g++ project.pro I can make a Makefile, and if I then do make it correctly makes the application. However, when I then send the complete folder to the other person in the project and he does make he gets the error
Makefile:209: warning: overriding commands for target `moc_window.cpp'
Makefile:203: warning: ignoring old commands for target `moc_window.cpp'
make: *** No rule to make target `/usr/lib64/qt-3.3/mkspecs/default/qmake.conf', needed by `Makefile'. Stop.
However, when in the same folder he does qmake; make it does work correctly. The problem is that when handing the code in we don't know if the professor has qmake available, so we would like it to work by only using make. Are we missing something that should be addded to have the Makefile made with qmake work, without having to do qmake again? Our .pro file is below.
TEMPLATE = app
TARGET = smoke
QT = core gui opengl
greaterThan(QT_MAJOR_VERSION, 4): QT += widgets
SOURCES += \
fluids.cpp \
simulation.cpp \
visualization.cpp \
window.cpp \
myglwidget.cpp \
vector.cpp \
grid.cpp \
scalar.cpp
HEADERS += \
window.h \
myglwidget.h \
simulation.h \
vector.h \
grid.h \
visualization.h \
scalar.h
INCLUDEPATH += fftw-2.1.5/include /usr/local/include include
LIBS += -L"$$_PRO_FILE_PWD_/fftw-2.1.5/lib" -lrfftw -lfftw -framework OpenGL -framework GLUT -stdlib=libc++
QMAKE_CXXFLAGS += -stdlib=libc++
QMAKE_CXXFLAGS += -std=c++11
FORMS += \
window.ui
The build directory is not portable. It is only ever meant to work on the system where you executed qmake, and for the particular Qt install that you ran qmake from. Recall that each Qt install has its own qmake, so e.g. if you have three Qt versions, each provides its own qmake that you must use to build a project using that version.
The project you ship should contain the .pro file, the sources, and whatever else the build calls for, like icon files, resources, etc.
The recipient, to build it, should:
Create a build folder.
cd into the build folder.
qmake /path/to/sources/project.pro && make -j
That's how you distribute and build Qt projects.
why does qmake not build the application directly?
Why do you not make your own shoes? The reasons are the same. Don't reinvent the wheel.
Of course, engineers sometimes have an itch to scratch. Enter Qt Build System (qbs). If your project's build is given as a .qbs file, then you do:
Create a build root folder.
cd into the build root folder.
qbs -f /path/to/sources/project.qbs - this builds the project.
I'm using Qt 5.1.1 and running qmake on windows.
I run qmake with the following command:
qmake.exe -spec win32-msvc2012 -tp vc project.pro
Somehow in my makefile it generates some weird relative paths:
INCPATH = -I"..\..\..\qt\qwt-6.1.0\src"
for example.
My includepaths in the .pro file are the following:
INCLUDEPATH += \
$$PWD \
$$QWTDIR \
what did I do wrong? (The compiler searches for ......\ which it isn't allowed to access for sure)
qwtdir is defined as:
QWTDIR = C:/qt/qwt-6.1.0/src
I resolved the error. Someone committed corrupted .pri file which didn't contain a proper line break after an include i.e.:
HEADERS += \
$$PWD/file1.h \ $$PWD/file2.h
Adding a proper line break solved the issue.
INCLUDEPATH += $$PWD is most likely unnecessary.
Your $$QWTDIR is relative, most likely - you'd need to relent and show it to us. Use $$absolute_path($${QWTDIR}).
You could also probably put the include paths all on one line. The trailing line continuation in the last line of INCLUDEPATH is wrong, you must remove it:
INCLUDEPATH += \
$$PWD \
$$QWTDIR
You are trying to build against the source tree of Qwt ( probably copying the project files of the Qwt examples ) instead of installing Qwt properly and building against the installed version using:
CONFIG += qwt
See http://qwt.sourceforge.net/qwtinstall.html
I have a problem with my Makefile. I downloaded opensource Qt project. Hence, when I try to compile it I got a message:
error: No rule to make target needed by stop.
In my .pro file I have relative paths to *.cpp files. So when I replace relative paths to absolute it works, another case it got me with the error above.
System is Linux.
What should I do to do this work with the relative paths?
I would use QtCreator, opening the project and then adding one of the misplaced sources (let say the first you see in .pro).
The IDE should place it with the correct relative path, as appropriate per your folder choice. After that cut'n'paste the path prefix all over the remaining places.
Anyway, path prefixes should be relative to the directory where you find the .pro. An example from an opensource project I'm using (QZXIng, a Qt port of ZXing):
SOURCES += CameraImageWrapper.cpp \
QZXing.cpp \
imagehandler.cpp \
zxing/ResultPointCallback.cpp \
zxing/ResultPoint.cpp \
zxing/Result.cpp \
...
so you could try to move the .pro file where appropriate instead of changing relative paths...
One reason for this issue is because you have removed a file which you no longer need but forgot remove from res.qrc
I had this issue and it was because I had the wrong Kit selected under Projects>Build & Run
I have the same error. My pro file was
HEADERS = \
charectertranformer.h \
filereader.h \
svgview.h \
threadfilereader.h \
serverworker.h \
renderserver.h
SOURCES = \
charectertranformer.cpp \
filereader.cpp \
main.cpp \
svgview.cpp \
threadfilereader.cpp \
serverworker.cpp \
renderserver.cpp \
QT += concurrent
QT += opengl
QT += network
QT += svg
CONFIG -= console
#CONFIG += warn_off exceptions_off
#qmake -svgviewer.pro
deleting backslash after renderserver.cpp helps me