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:

  • Cross toolchain GCC 6.3.0 for Stretch: here.
  • Cross toolchain GCC 8.3.0 for Buster: here.

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”

  1. Hi Luca! Thank you for the toolchain!
    One more question, on pi4 are you using kms or fake kms?


      1. 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?

          1. 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.

                  1. 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.

                    1. 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 …

                    2. 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.

                    1. 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.

                    2. websocket and the others should be built separately by the qt-configure-module script

  2. 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.


  3. 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,

    1. 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.

    2. Hi Thomas,

      Would you mind sharing the steps you took to achieve this? I am struggling with cross compiling Qt for Pi4 Raspian Bullseye.



        1. 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

Leave a Reply

Your email address will not be published.