an absolute failure – unable to build qt5 on a raspberry pi 4

Making Qt5 with all four cores running, and Chromium sitting on the desktop.

One of the benefits of sheltering in place while waiting for Dorian to arrive is I’ve “found” the time to do a bit of development on the still newish Raspberry Pi 4 4GB. Early I’d formatted and attached a $57 Crucial MX500 500GB SSD to one of the Pi’s USB 3 ports, and had set up shop on it to build software. I’d mounted the MX500 on /ssd and I’d modified /etc/dphys-swapfile to place the swapfile on /ssd/swap, with my usual 2GB of space.

My first cross compilation task was with Qt version 5.13, with the installation area /ssd/Qt5. It seemed to actually build with all defaults except where to install it, which I obviously changed to keep off the micro SDXC card. At least I thought it’d successfully built  until I tried to run one of the UI examples, and it failed with:

* failed to add service - already in use?

Which has to be one of the most crypticly stupid error messages I’ve ever seen. I then set QT_DEBUG_PLUGINS equal to 1 and ran it again. Got lots more text, but nothing that explained anything:

...
Got keys from plugin meta data ("xcb_egl")
QFactoryLoader::QFactoryLoader() checking directory path "/ssd/Qt5/examples/widgets/widgets/analogclock/xcbglintegrations" ...
loaded library "/ssd/Qt5/plugins/xcbglintegrations/libqxcb-egl-integration.so"
* failed to add service - already in use?
...

I’ve been hunting all over the web, and found what I thought might be useful help, but it was no help at all. I wrote a wrapper script to run configure, disabling various things, and went so far as to create a unique mkspec to pick up the architecture that matched the Raspberry Pi 4:

include(../common/raspberrypi.conf)

QMAKE_CFLAGS += -march=armv8-a -mtune=cortex-a72 -mfpu=crypto-neon-fp-armv8
QMAKE_CXXFLAGS = $$QMAKE_CFLAGS

load(qt_config)

Which I copied from an existing mkspec for the Raspberry Pi 3, changing mtune from cortex-a53.

I built three individual released (5.11, 5.12, and 5.13). I built 5.11 since that matches what is installed with PyQt5 from the repo, but that failed as well. I finally gave up when my last run produced this during ‘make install’:

 #    error "Not supported ARM architecture"
      ^~~~~

while trying to install JavaScript support. Ok. You win. It was trying to build JavaScript JIT for Qt’s Designer that pushed me in this direction, because the prebuilt one for Raspbian is so damn slow because it doesn’t have the JavaScript JIT compiler. So no practical native JavaScript support on Qt, in spite of full blown high performance JavaScript support in node.js as well as Chromium. It’s Qt5’s attempted implementation that is so broken on this platform.

I did gain a fair bit of positive knowledge in spite of ultimate failure:

  • I learned how to install an SSD on the Raspberry Pi 4
  • I learned that reads and writes on this SSD are very fast and make working on the Pi 4 even more pleasant.
  • I have an even deeper respect for the Flirc case than before. I had make using all four cores, and the temperature never rose above 65°C the entire time.
  • You can still hit swap even with 4GB, but hitting swap on the SSD is far preferable to hitting swap on the micro SDXC card.
  • The Pi 4 with a decent SSD attached makes this a real “personal computer”. I have had Chromium open with multiple tabs while the build was consuming all four cores, and I never had any performance issues working on the graphical desktop.

I firmly believe that native development on the Raspberry Pi 4 with this setup is far more reasonable than with any other Raspberry Pi before this, and that you need to purchase the Pi 4 with 4GB of memory.

Now if I can just get good news with regards to hurricane Dorian…

Advertisements

5 thoughts on “an absolute failure – unable to build qt5 on a raspberry pi 4

  1. Welcome to my world. But instead of QT I’m using Kivy and bleeding-edge enthusiasts other than myself are also suffering. And yet, perhaps 50% of the people attempting to get full-screen Window support on their Raspi4B are having problems.

    To me, it feels like some of the drivers just aren’t there yet. The Pi4 appears to support OpenGL ES 3.0 believe it or not, at least that’s what it’s showing up as. The problem is that many of these support layers and libraries are either compiled with 1.0 or 2.0 versions of same. I’m not convinced that there even are C headers for GLES3.0 yet. Many of us are patiently waiting for this to fix itself in some update. The fix might ultimately be to 1) wait, 2) do `sudo apt-get update && sudo apt-get upgrade` in the future, 3) rebuild.

    That said, I was able to get a simple Hello World app to create a window in Raspbian Buster Desktop with Kivy 1.11.1 and Python 3 by only launching the app within a Terminal from the local Pi itself.

    Liked by 1 person

    • You would think that success building what already comes pre-built in the repos would be a foregone conclusion, but not here it would seem. If I can’t reproduce what’s in the repos, then what am I missing? Don’t get me wrong, I like the RPi 4. But this was rushed to market, from the use of step ‘B’ release silicon (overheating) to rough release drivers (USB overheating) to wiring mistakes on the boards themselves (I’m looking at you, USB C power connector). I can work around a lot of that with mechanical fixes (such as a Flirc box to hold the RPi4B and pull away most heat). As for everything else, I can wait and just use what’s already in the repos. Right now I’ve got Python 3.8 beta running and the latest GCC, 9.1, compiling away. I’ve got hardware hanging off the GPIO and I2C, so there’s that for me to experiment with.

      In the meantime I’ve got a hurricane to worry about. I just got a Tropical Storm Warning text from Orange County. Expect lots of wind and rain. Especially rain.

      Like

  2. Condolences on the hurricane. Here on the other coast this barely makes our radar except for the posts on here.

    The Pi4Bs were coming out to users before Buster was even carved in stone. We now have end-users clamoring for Pi4 support all over the place and no real answer to give anyone. (They thought it would come out in 2020, that’s what everyone was told earlier.)

    Liked by 1 person

    • As noted in a later post Dorian’s rain bands are finally moving over central Florida and Orlando.In another 24 hours hopefully everything will move out. The biggest question for me at least is how we’ll help those in Grand Bahama and Abaco.

      I was surprised when the Pi4 was released as early as it was. I can work with what it has so far and around the problems I’ve discovered until such time (probably next year as originally intended). In the mean time I’ve fallen back on the old stalwarts, as it were, such as emacs. Coming back to emacs is like coming home for me personally. The newer tools, languages like Rust and Go, seem to be working well in this environment as well. It isn’t perfect, but it all suits me fine in spite of everything.

      Like

Comments are closed.