Okay, I think I found what I was looking for. Instead of looking for the library in /opt/Qt-blah-blah, I needed to look at in the Ubuntu repositories for something named qml-module-qtquick. If this works out, I'll mark the question solved. If someone has suggestions, like "you usually need all these modules" or "here is a table describing the versions" I'll happily upvote their reply. (I don't see a way to credit someone with solving/answering the question, as is done on some of the other forums.)
I apologize for not providing more detail in the original question. These hosts are air-gapped, so I can't just do a apt-cache search qtquick.
@chris1092387456 could it be possible you have mixed Qt versions from the one you cross-compiled and the one it's used by the OpenCV install script you used.
Assuming you run Ubuntu/opencv_latest.sh which in turn calls opencv_install.sh and then dependencies.sh, there are some apt-get install calls, so you''ll end up having pre-built Qt libraries along with your cross-compiled ones...
Then I'd follow this guide to cross compile the latest version of OpenCV for Raspberry Pi. As you'll use WITH_QT=ON flag I guess, please adjust the paths in the CMake script(s) to use the cross-compiled Qt version in your host PC.
And also use the correct path for cross-compiled OpenCV in your .pro file. As example, the following doesn't look good to me:
@csaba911 You can't expect QtCompany to provide official Qt installers/binaries for every existing and future platform/hardware. This is simply not possible because of limited resources and time.
If you want to do cross compilation, then yes you have to learn how it works, this is life.
Did you check https://wiki.qt.io/Raspberry_Pi_Beginners_Guide ?
"Linux and Qt is so discouraging to use it, I don't understand people and their mind" - then don't use it, really...
I use both since many many years and don't want to use anything other than Linux for software development.
Posts like yours do not improve anything, sorry. Constructive critic, improvement suggestions and patches are welcome (this is how open source works).
I am running Lubuntu 19.04 on a mini-pc. I am developing an application on my desktop and want to deploy it on a mini-pc (both use the same architecture and binary compatible).
I want to avoid installing the whole qt (5.13) on the mini-pc. I remember in good old days it was enough to install 'qt-sdk' package...but I can not find that anymore...
Any ideas how to manage this?
sudo apt install qt5-qmake
or on some systems:
sudo apt install qt5-default
That will install the Qt libraries (not Qt Creator).
But if you really only want to deploy a working executable to your other machine, you should use proper deployment tool: create a DEB package or create an AppImage (or a Snap, or Flatpak), or compile statically. Some more info in the docs: https://doc.qt.io/qt-5/linux-deployment.html
From what you wrote, your build folder is inside Qt's sources folder. Change that and add -nomake tests -nomake examples. These last two flags will make you win time and disk space.
Alright, so I made a directory /home/pi/build I did the code there and I got the same error. I tried going a folder deeper and did /home/pi/build/qt512 and I still got the same error. qt-everywhere-src-5.12.3 and qt-raspberrypi-configuration folders are in the same folder directory (home/pi).
Are you saying that I have to take that I have to build this folder elsewhere?
EDIT: Appears that this was the issue, but I am now running into another issue, lol. Thank you on this solution.
Hi. I pretty much cross-compile everything for my many PIs using multiple versions of Qt (although 5.13.0 seems to work rather nicely). I run a Fedora host, although there is no reason this shouldn't work equally as well on any other distro. (If you're running Windoze you're on your own ;)
It took a bit at first. I have a script at https://github.com/StevePunak/KanoopCommonQt/blob/master/docs/configqt which I use to do my initial configuration.
Modify the locations at the top to suit your build system, then run this script from your new shadow build location to do your configure
Three big tips to avoid unnecessary pain are:
Never build in source. Always use a shadow directory. Wherever you have the Qt source, make a directory for the build at the same level as Src/, and build there. You can rm -rf the contents of this shadow directory to get a complete clean
Before you even start trying to build, fix the symbolic links on your PI directly by using the symlinks utility 'apt-get install symlinks' and running 'sudo symlinks -c .' in /usr/lib/arm-linux-gnueabihf and /etc/alternatives'
If possible, DO NOT create a sysroot on your host. Instead use sshfs to mount your PI and use that as your sysroot. That way you will always be in sync when you install new dev packages on your PI. I can not tell you how much time that has saved me!
Running Windows Runtime device detection.
No winrtrunner.exe found.
But that's something new. You now seem to somewhere have a WinRT alias UWP kit selected.
As I said before: I'd start with installing exactly ONE Qt MinGW version (I recommend 32 bit) and ONE MinGW compiler. Nothing else.
Then make sure you eleminate everything unneeded from the PATH variable before starting Creator.
Then create a new example (make sure nothing is left from previous attempts, especially no .pro.user and Makefiles).
Then qmake will generate Makefiles in the build folder, which in turn are used from make to generate your program. make will call the compilers to compile and the linker to finally link your program. If any of these calls pick the wrong program from the PATH, it will fail.
We already know that something at this point went wrong, so if it still goes wrong we need to analyze the Makefiles. But I think that really has to do with some other program in your PATH.
Changing the '\' to '/' in QtStaticDir (e.g. from C:\Qt\5.13.0\mingw73_64_static to C:/Qt/5.13.0/mingw73_64_static) did not work for me.
I'm having the same problem using Windows 10 x64, Qt 5.13.0 and MinGW 7.30 64-bit
So we have established that the problem is not specifically with the 5.12.3 version of Qt (5.13 is affected too), nor the 32-bit version of MinGW (the 64-bit version is affected too).
It is unfortunate that the bug report in bug tracker was closed (twice!): https://bugreports.qt.io/browse/QTBUG-68502 https://bugreports.qt.io/browse/QTBUG-72585
The claim by the person who closed it was that this is not a Qt problem. There is clearly an issue with the way Qt sources interact with the compiler that Qt is distributing, affecting users who follow the instructions on static builds that are given on the official Qt website: this sounds a "Qt problem" to me, even if "it's someone else's fault".
I'll keep trying to find a solution and post back here.
Thanks for reporting back. However,it would be good to checkin the bug report system for Qt https://bugreports.qt.io/secure/Dashboard.jspa if there is already a bug report on this issue. If not,you should add it and post the bug report number here.
This forum is not checked for bug reports and it will be lost when not entered as a proper bug report.
@J.Hilk Thank you. Can you please help me with cmake. How do i set the cmake for desktop (5.12.4 MinGW-64 bit) . Currently when i create the ArcGIS QML app and run through the desktop kit it says "error: FS/No such file or directory".
Ok. I found the cause why I was not getting anything QML related from the tool. My widget is not in the exe file but in a DLL so I had to specify the dll instead.
But the list of files the tool is getting is huge compared with the one I got by doing the process "manually" and includes most of the .qml files. So my doubt is, do we need to deploy all this files with my application? is not enough with the dlls???
@Pablo-J.-Rogina Thank you very much Pablo 😃 the blog was really helpful and explained every step.
One last problem remained .. the setup breaks at 38% when building dependencies for core. It seems that some files may have a bug but i really doubt about that.
The errors are:
'to_string' is not a member of 'std'
control reaches end of non-void function [Werror=return-type]
I'll try the version of OpenCV that Amin Ahmadi recommended in the blog and hope that it works.