Raspberry OS Bullseye and Cross Toolchain for Linux and Mac OS 10.2.1
Raspberry OS based on Debian bullseye was recently published. The compiler provided with this new version was updated to 10.2.1. As usual, I need to cross build many large projects for the platform, and I had problems in the past with cross toolchains not precisely matching the versions in the target sysroot. I therefore typically prefer to build my own toolchains based on the precise versions of the packages provided with the OS. These are the toolchains I’m using for the past Raspberry Pi systems:
For Bullseye, these are the new toolchains I’m currently using:
- Cross toolchain GCC 10.2.1 for Linux hosts for Bullseye: here.
- Cross toolchain GCC 10.2.1 for Mac OS hosts for Bullseye: here.
As usual, place the toolchain in /opt/rpi, and the sysroot in /opt/rpi/sysroot. I tested these toolchains to build Qt 6.2.1 and everything seems to be fine so far.
Have fun! Bye 😉
22 thoughts on “Raspberry OS Bullseye and Cross Toolchain for Linux and Mac OS 10.2.1”
Leave a Reply
Related Post
Docker Image for Qt Development and Continuous Integration for Linux and Android
Sometimes I need to have specific versions of Qt to build apps and run CI [...]
Hi Luca! Thank you for the toolchain!
One more question, on pi4 are you using kms or fake kms?
Regards,
Mattia
Hello,
it depends on the project, but more frequently fkms.
Building Qt 6.2.2 I get these errors from cmake:
/opt/rpi/rpi-gcc-10.2.1/lib/gcc/arm-linux-gnueabihf/10.2.1/../../../../arm-linux-gnueabihf/bin/ld: warning: libGLdispatch.so.0, needed by /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libEGL.so, not found (try using -rpath or -rpath-link)
/opt/rpi/rpi-gcc-10.2.1/lib/gcc/arm-linux-gnueabihf/10.2.1/../../../../arm-linux-gnueabihf/bin/ld: /opt/rpi/sysroot/usr/lib/arm-linux-gnueabihf/libEGL.so: undefined reference to `__glDispatchGetABIVersion’
(continues with others undefined reference)
I’m sure that libGLdispatch.so.0 is inside sysroot lib folder. Anyone have faced with this issue?
Are you sure it is not a broken symlink?
Yes, I have also changed the symlinks with the real file, with no luck.
I have compiled Qt 5.15.2 with the same sysroot without troubles, but I noticed that configure found both EGLFS Device and EGLFS Raspberry so I have edited qtbase/src/gui/configure.json to make test EGLFS Raspberry fail.
And did you do what the linker suggests?
Ok, I added the rpath-link and now the is issue is fixed. Thank you
Where and how you have defined the rpath-link? I am faced the same issue now …
One solution is to do it in your cmake toolchain. Otherwise it is probably possible to do it in the sources, in the configure command line or maybe even with env variables. I did not actually try it, but I suppose it is possible.
Thank you for the prompt reply. The only issue that casts a shadow on your toolchain, that it does not compile Qt 6.2.2 with EGLFS (for Rpi4) because of this rpath-link issue:
– the configure supports only -rpath, not -rpath-link (I assume they are different) and it does not really have any effect on the Qt6 compilation
– the toolchain.cmake: I could put rpath there, but not yet figured out how to put rpath-link too
– I could set -L for all possible params, but your toolchain’s ld did not consider them
I just wondering, how Mattia could solve this …
Just to follow up for people findig this site with the same issue. For me, at this moment, it solved the issue when I have added “-Wl,-rpath-link,/path/to/lib” to CMAKE_EXE_LINKER_FLAGS
Not sure this is the best solution, but it does enable Qt 6.2.2 cross compilation (with EGLFS) with luca’s toolchain.
You have found my same solution!
Oh, I am happy for that. 🙂
Btw, did you manage to compile websockets? It seems that is not compiled out-of-the-box for 6.2.2.
websocket and the others should be built separately by the qt-configure-module script
Hi Luca,
Thanks for the Mac OS X tool chain. In order to use it I needed to create the following directory and symbolic link:
sudo mkdir -p /Users/Luca/projects/pi/pi/piomxtextures_tools/bullseye/toolchain/macOS/
sudo ln sudo ln -s /opt/rpi/rpi-gcc-10.2.1 /Users/Luca/projects/pi/pi/piomxtextures_tools/bullseye/toolchain/macOS/
It looks like some of the dependencies are linked to your build directory.
In addition I used the following command to disable the Gatekeeper warnings (untrusted developer):
sudo spctl —master-disable
With these changes I was able to successfully cross-compile Qt5.15.2 on macOS Monterey 12.0.1.
Thanks
Uh! This looks like a mistake… I’ll have to check that. Thanks for pointing it out.
Hi Luca,
Your Bullseye toolchain is as good as the previous one for Buster and Stretch 😉
I’ve been able to cross build QT 5.15.7 and all its modules (including QtWebEngine) without any problem on a linux host (an azure ubuntu server 20.04)
If you have the time to share, I would be interested in reproducing the steps you’ve followed to build this toolchain because all my attempts with crosstool-ng are always unsuccessful (following this tutorial for instance : https://ilyas-hamadouche.medium.com/creating-a-cross-platform-toolchain-for-raspberry-pi-4-5c626d908b9d)
Best regards,
Thomas
Hello! Good to hear that!
I did not use crosstool-ng. I built the components manually. You can find a huge amount of tutorials online. I followed those.
Hi Thomas,
Would you mind sharing the steps you took to achieve this? I am struggling with cross compiling Qt for Pi4 Raspian Bullseye.
Regards
Mike
There are many tutorials on how to build Qt. You probably want to share the specific error if you want someone to answer.
Hi Luca,
Sorry for the late reply, I tried to reproduce the error I stumbled upon but finally managed to build it successfully using your toolchain. Thanks
Very good then!