Build qt for raspberry pi3 arm64 - c++

I try to set up a cross compile build environment for raspberry-pi3 qt5.12 application. The target will run ubuntu 64bits (raspberry version) os and the host runs ubuntu 18.04 x86-64. I tried several tutorials found on the internet like this one :
https://medium.com/#amirmann/how-to-cross-compile-qt-for-raspberry-pi-3-on-linux-ubuntu-for-beginners-75acf2a078c
I try to set up this environment to put CI/CD for raspi application so I'd like to set it up without the raspberry physically connected to the host, only a mounted image if possible or a qemu process.
Whatever I try to do, the qt configuration failed with the following error :
$RPI_TOOLS/..../ld: cannot find crt1.o : No such file or directory
$RPI_TOOLS/..../ld: cannot find crti.o : No such file or directory
$RPI_TOOLS/..../ld: cannot find -lm
I tried to export a $LIBRARY_PATH environment variable with the path to those files but nothing changes.
Does anyone have already compiled qt 5.12 for raspberry pi3 64bits and can give me some clues/tutorials/help on how to do it ?
Thx guys

I fix my issues with the option -xplatform linux-aarch64-gnu-arm when starting qt configure script. Before this I chroot into the raspi-rootfs with qemu-static and install the dependencies with apt.

Related

Qt cannot load cocoa plugin

I'm trying to compile and run an application on a MacBook using Qt Creator. There are no issues compiling the project, but when I try and run it, it seems to be unable to load a plugin.
Could not load the Qt platform plugin "cocoa" in "" even though it was found.
The application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
This error occurs both when trying to run the application from Qt Creator or via Finder. It seems to only happen when I use the CMake build system (no issues when using QMake), but my existing project that I need to deploy on MacOS uses CMake.
My steps to reproduce are:
Install a completely clean MacOS (no user data)
Install Xcode 11
Install CMake 3.15
Install Qt 5.13.1 MacOS package
Open QtCreator->New Project->Qt Quick Application - Scroll
Set build system to CMake (important)
Compile and notice error
I am using:
Qt 5.13.1
macOS Catalina 10.15
Apple Clang 11
I recognize that for final user deployment I will need to use the macqtdeploy tool to copy the Qt libraries to the executable folder, but I should be able to run my app from QtCreator without doing this? Especially as it works fine when using QMake.
So it ended up being some kind of name resolution thing where Qt Creator couldn't decide whether to use the debug or release versions of the framework. Supplying DYLD_IMAGE_SUFFIX=_debug fixed this (add this to the environment section under Kits).

How Qt's example built during cross compiling qt compared to run qmake after compiling?

FIRST, it's not the issue that Qt CANNOT found target .so, qt can found it, but it failed to load it and produce not logs... on both terminal and gdb. It seems that qmake/make is using wrong library but I have only one qt installed in my cross compile environment that generated by make install.
I'm struggling for cross compiling qt5.10 for raspberry pi on Windows. I'm using msys2, gnutoolchains's raspberry chains.
The problem here is the examples built by the compiling process runs almost no problem, I only needs to add a qt.conf to fix the prefix override by msys2 and it can run and display something on my pi.
But when it comes to qt creator, or qmake out of cross compiling, it starts to show me:
This application failed to start because it could not find or load the Qt platform plugin "xcb"
Here are two problems, first, the platform plugin should not be xcb since I'm running without x, cross compiled version will use eglfs by default.
And, second, even I specific platform plugin to eglfs, it still tells me it cannot load eglfs.
I'm putting two version of programs in the same place.
qt5pi/examples/opengl/2dpainting $ ls
2dpainting glwidget.cpp helper.h widget.cpp window.h
2dpainting.pro glwidget.h main.cpp widget.h
2dpaint_my helper.cpp qt.conf window.cpp
2dpaint_my is compiled by qmake && make and 2dpainting is by qt's cross compiling process uses the same source.
I'm suspecting qt is adding something during it's cross compiling, but I'm not sure how it happened. Qt'wiki about raspberry pi contains nothing about this issue.
update
It looks even wired to me. I copied a running example from its folder to another and it also crash, things look like this..
pi#raspberrypi:/usr/local/qt5pi/examples/qt_test $ cp ../opengl/2dpainting/2dpainting .
pi#raspberrypi:/usr/local/qt5pi/examples/qt_test $ ./2dpainting
This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".
Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen,vnc, webgl, xcb.
Reinstalling the application may fix this problem.
Aborted
pi#raspberrypi:/usr/local/qt5pi/examples/qt_test $ ../opengl/2dpainting/2dpainting
qt.qpa.egldeviceintegration: EGL device integration plugin keys: ("eglfs_brcm","eglfs_emu")
qt.qpa.egldeviceintegration: EGL device integration plugin keys (sorted): ("eglfs_brcm", "eglfs_emu")
qt.qpa.egldeviceintegration: Trying to load device EGL integration "eglfs_brcm"
qt.qpa.egldeviceintegration: Using EGL device integration "eglfs_brcm"
qt.qpa.input: Initializing tslib plugin "TsLib" ""
qt.qpa.input: tslib device is "/dev/input/event0"
I'm not sure, but it seems that the this step on qt'wiki introduced some qt5.7 files into lib folder.
sudo apt-get update
sudo apt-get build-dep qt4-x11
sudo apt-get build-dep libqt5gui5
sudo apt-get install libudev-dev libinput-dev libts-dev libxcb-xinerama0-dev libxcb-xinerama0
The problem is, qt's examples, when it on their own folders, can magically find (maybe qmake install did something?) and use the correct *.so, and so it works without problem.
But, when compiling with qmake, the program won't find the correct libraries so, newer libq*.so with older libQtXXXXX.so lead to this probleam. And that's how it uses a different qt version with compile.
And, that indicates the optional 00- in step 13 from the wiki:
[on RPi] Update the device to let the linker find the Qt libs:
echo /usr/local/qt5pi/lib | sudo tee /etc/ld.so.conf.d/qt5pi.conf
sudo ldconfig
If you're facing issues with running the example, try to use 00-qt5pi.conf instead of qt5pi.conf, to introduce proper order.
should be taken even the examples run without problem.

No configure file to make static version of qt

I want to deploy my qt program using static linking following this documentation:
http://doc.qt.io/qt-5/linux-deployment.html
When I try the command "./configure -static -prefix /usr/bin", I get an error:
"bash: ./configure: No such file or directory"
I understand that happens because there is no configure file. In the documentation it says "/path/to/Qt". /usr/bin seems to be the path where qt is installed.
Why is it not working? Am I in the wrong directory?
I wrote the application in C++ using the Qt Creator on a Raspberry Pi 2 with Raspbian Jessie. I want to deploy it so I can use it on another Raspberry that has minimal functionality without desktop-gui or qtcreator installed. I am using Raspbian Jessie Lite on that one.
I had this same problem after installing qt creator 5.10.
The qt directory does not have a configure file. However, the source directory for qt does.
In my installation, that is:
~/qt/5.10.1/Src
If you cd into that directory, you can run the ./configure command. At least i am able to.

Ubuntu 14.04 LTS x86-64bit Qt Creator 3.0.1 Kit Qt 4.8.6 Failed to start program. Path or Permissions Wrong?

I am trying to run a program in Qt Creator version 3.0.1, compiled on a 64-bit version of Ubuntu 14.04 using Qt 4.8.6. I have searched through other posts relating to the topic, and odds are that there's a conflict between 32-bit and 64-bit executable files. However, what is surprising to me is that the program was running just fine with no problems on the exact same environment two hours ago.
The error being returned is:
Failed to start program. Path or permissions wrong?
Again, I know that there might be a problem with the 32-bit and 64-bit stuff. I checked the executable with ldd and I got:
not a dynamic executable
This says to me that the executable cannot be run. But I still don't know why, because as I said, I was running the program two hours ago and it was working fine.
In fact I am fairly sure now that it is one of the following:
Try (where program is the name of your executable):
In a terminal cd /path/to/your/executable. Then `./program'
If that does not work do sudo chmod 777 program and try again.
If / when you get this running in a terminal try looking in QtCreator build path under Projects --> General --> Build Directory and check this path is correct.
In QtCreator check the Run Settings --> Working Directory
It could be that you are running Qt as your normal user when before you where running as admin (or visa versa) and so either your paths have changed or the permissions are different.
I had a look around the web and found similar issues as well, this looks the same to me and I do recall something like this when running as admin once...

Cross-Compiling Qt for Embedded Linux Applications

Where qmake.conf file is located and how it should look for armhf debian wheezy platform? (BeagleBone Black)
I am trying to follow these steps, but some of them are unreasonable like that one about qmake.
Also what does export PATH=path/to/cross/compiler:$PATH will do?
I enter something like this in path/to/cross/compiler
export PATH=/usr/bin/arm-linux-gnueabihf-g++:$PATH
export PATH=/usr/bin/arm-linux-gnueabihf-g++:$PATH
you should add directory to PATH not path to file, in your case it is /usr/bin,
but because of /usr/bin is already in your PATH you can skip this step.
Where qmake.conf file is located and how it should look for armhf debian wheezy platform?
Look at mkspecs/linux-arm-gnueabi-g++/ in qt source directory, your qmake.conf should looks like it, you can just modify this file to point to your compiler.
After a week of trying to configure arm qt cross-compiler on my Debian 7 Wheezy, I decided to try to follow these steps on Ubuntu 14.04, and everything went as expected! So, don't lose your time playing with Debian Wheezy host machine, try with newest Ubuntu distribution and save your time!