I am trying to compile QT for ARM.
But the linker requires "--sysroot" option to be added for linking files.
So in qmake.conf file, we added under QMAKE_LFLAGS.
But when we compile, its adding this even for initial tools build on the x86 PC. So gcc complains and gives error.
The cross compiler tool chain which doesnt have a .pc file.
Please let me know where to add the "--sysroot" so that this is added only when it tries to cross compile.
Thanks.
Hari
You can do this using qmake scopes - specifically platform scope variables. To ensure that -sysroot is only evaluated for your ARM builds you can do something like this:
arm-linux: {
QMAKE_LFLAGS += --sysroot
}
You may need to change the scope, depending on the platform you're actually targetting.
Related
I need to compile a cocos2dx project on Windows 10 which has some objective-c++ code, and all that using QtCreator. I've managed to set the compilers in the kit to LLVM (so that objective-c++ code can be compiled), as well as change the qmakespec to win32-clang-g++, however, I'm still getting this error when trying to compile:
error: No rule to make target 'C:/Qt/Qt5.12.9/5.12.9/msvc2017_64/lib/libQt5OpenGLd.a', needed by 'debug/libcocos2d.a'. Stop.
The folder in question contains file Qt5OpenGLd.lib, but doesn't have libQt5OpenGLd.a.
How do I fix this? I can provide more info, but I'm not sure what info is relevant.
I had to use win32-clnag-msvc in order to have it compile a .lib file instead of .a file.
So, there I'm writing some library and desided to have a proper unit-testing for it (like TDD and so on). QtTest framework looked suitable to start with. The library itself is fine, so is the test.
But when I added both the library and the test project to my job project, CI build surprisingly failed. It occured that the test executable (LibraryTest.exe or similar on Linux) was being copied:
to %QTDIR%/tests in a separate folder on Windows
to /usr/tests on Linux
My test project settings added this behavior to the "install" build stage, there they are (important ones):
QT += core testlib
# The problem is below
CONFIG += c++11 qt warn_on depend_includepath #testcase
CONFIG -= app_bundle
LIBS *= -L$$PWD -lmylibrary # not exact, does not matter
TARGET = LibraryTest
SOURCES += \
tst_my_library_test.cpp
DEFINES *= QT_FORCE_ASSERTS
DESTDIR = $$PWD/bin
As you can see, after commenting out CONFIG += testcase the executable is not copied somewhere anymore. I've read that this configuration option is used for automated tests, that looks useful, but nothing is written about any special install stage. The test executable exists in the DESTDIR just fine, so it is not some accident error.
My question is: why is it happening? Can I specify some other folder?
Automation is usefull, but even if implemented it would be probably bound to some more convenient directory.
Am I cooking the QtTest wrong? Thanks in advance for your attention.
Okay, after hacking the tests in my own way and getting enough time to study the problem thoroughly it occured that Qt's tests are designed to be used in a quite another way than I've thought.
It was obvious, that the testcase's makefile differs from the regular one, but the official documentation just stated the following:
For testcase projects, qmake will insert a check target into the generated Makefile. This target will run the application. The test is considered to pass if it terminates with an exit code equal to zero.
This gave a hint, what exactly resulted in makefile having extra install_target: first FORCE with strange and wrong file copying, but didn't explain the behavior deeper.
After some more seraching I found the following here:
Note also that Qt tests have only been tested with a non-installing Qt (the -prefix $PWD option above). The test project files override the make install target, so they are not installable. And Qt doesn't work at all if it's not at its installation path.
As far as my project uses heavilly the install build step and the tests were part of the project tree, it explained the problem.
In my Android native project, I need to use some core Qt functionality. Following the instructions at http://qt-project.org/wiki/Qt5ForAndroidBuilding, I managed to build Qt for Android. I can see that all the generated archive files are stored in qtbase/lib directory.
I am linking my C++ code with libQt5Core.a, libQt5Bootstrap.a, and libqtpcre.a. Almost all of my Qt references are resolved exception two non-qt references - compress() and uncompress(). I have searched for these symbols in qtbase/lib/*.a files but haven't found any definition.
So where are these two functions defined? Are they in one of the standard NDK libraries or do I need to build something separately?
It seems qbytearray.cpp is using these two functions. It seems these functions are defined if QT_NO_COMPRESS is not defined. Looks like I could get away with the unresolved errors if I could somehow define QT_NO_COMPRESS. How do I define this? Do I pass it to configure script?
$ ./configure -DQT_NO_COMPRESS ...
Hoping I could simply find references to the missing functions. Otherwise, please advice on how to achieve the second option. Regards.
It turns out zlib is already part of Android NDK. All that was needed was -lz flag:
LOCAL_LDLIBS += -lz
I had a kit set up in Qt Creator 3.0.1 that pointed to my cross toolchain. This worked until I ran into a bug in the compiler and now have to upgrade to a newer version.
I've obtained a newer toolchain. I went into Creator, edited my kit, and updated the path to the compiler and gdb binary to point to the new toolchain.
However, when I build my project, it's still calling the old toolchain's compiler.
I've even completely deleted my kit, compiler, and debugger and recreated their configuration, but no joy.
I double-checked the mkspec that is being used, and there is nothing in there with hardcoded paths to the compiler, just things like QMAKE_CXX = $${CROSS_COMPILE}g++. I don't have the CROSS_COMPILE variable set. I did try setting it (in Creator's build environment editor) but no joy there either.
How do I get Creator to use my new toolchain?
EDIT - NEW INFO
I tried running the same qmake command line Creator does when it builds (according to its build output). First, the call to qmake I'm making is returning to the command line without creating a makefile. Here is the command I'm running:
/qt5/bin/qmake /s/src/tfs/porject_dirs/Myproject.pro -r -spec devices/linux-am335x-g++ CONFIG+=declarative_debug CONFIG+=qml_debug
So, I added a -d to get some qmake debug output. I found some fishy lines that pointed to some files that are in my mkspecs directory.
What are these files that were installed when I built Qt?
qconfig.pri
qdevice.pri
qfeatures.pri
qmodules.pri
Three of the four (not qfeatures.pri) include in them hard coded paths to the compiler I used to build Qt. I suspect that these are my problem.
Why does Qt Creator allow a compiler to be specified if these files might be overriding it? Is it safe to edit these files? Do I have to rebuild Qt simply to change the compiler used to build my application?
There is, an open bug in Qt that leaves hardcoded paths in the .pri files mentioned in my question.
Update
The bug has been resolved.
I've been working on a project using OpenCV for a while, and am ready to upgrade my user interface from using cvWaitKey() to get key presses and emulating buttons with trackbars. Ha. So I've decided to use Qt.
I'd like to continue developing in the same directory I've been using, which is, of course, outside of the Qt install directory, C:\Qt\2010.05\qt. Using the "Qt Command Prompt", I'm able to compile the Hello Notepad example in directories both in and out of C:\Qt\2010.05\qt, namely C:\Qt\2010.05\qt\abc and C:\Qt\2010.05\abc.
However, while compiling under C:\ ... \qt produces executables in both the debug and release directories, compiling outside of it only produces the debug executable, along with a .o file (object code?). I did some comparisons using WinMerge, and found that the following lines (among others) differ in the two makefiles (generated using qmake -project and then qmake):
Inside qt\
first: all
install: debug-install release-install
uninstall: debug-uninstall release-uninstall
Outside qt\
first: debug
install: debug-install
uninstall: debug-uninstall
That's clearly the problem (the .pro files generated by qmake -project differ only in timestamp). I'm sure there's an easy answer out there to what's causing this... I hope there's an easy answer to how I can work around it. Also, I intend to use QtCreator some; hopefully the solution is the same for the IDE as the Command-Line compiler.
Thanks!
Nolan
p.s.: I don't think this is the same issue: Qmake does not support build directories below the source directory ...in any case, I'm not sure I understand the answer.
You should be able to add
CONFIG += release
to your .pro file, to build for release target. There's also
CONFIG += debug_and_release
iirc.
QtCreator has a GUI element for toggling between build targets, you might try opening the .pro with that application if you find you need to switch back and forth often.