1

I had successfully cross-compiled Qt 5.11.2 for Raspbian Buster on Ubuntu 18.04 host mostly using these guides:

https://www.ics.com/blog/configuring-qt-creator-raspberry-pi

https://wiki.qt.io/RaspberryPi2EGLFS

(I had to tweak a couple of things, using the /gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf compiler and replacing ~/ with /home/{username} etc.)

But I ended up with a working Qt distro on the Pi and could cross-compile and debug remotely, runnning an example app with -platform xcb to use X11.

I then discovered that the official Raspberry Pi toolchain is woefully out of date (GCC 4.8.3) and my real-world app needs more up-to-date C++ features.

So I found a more recent GCC toolchain here: https://github.com/Pro/raspi-toolchain

I rebuilt Qt from scratch using the same sysroot as before and exactly the same configure options.

However, the resulting build Of Qt now does not include XCB support. If I delve into qt-everywhere-src-5.11.2/config.tests/xcb and make, compilation fails with this:

/opt/cross-pi-gcc/bin/arm-linux-gnueabihf-g++ -c -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard --sysroot=/home/nick/raspi/sysroot --sysroot=/home/nick/raspi/sysroot -O2 -w -fPIC  -I. -I/media/nick/CrossCompile/raspi/qt-everywhere-src-5.11.2/qtbase/mkspecs/devices/linux-rasp-pi3-g++ -o main.o main.cpp
main.cpp:2:10: fatal error: xcb/xcb.h: No such file or directory
 #include <xcb/xcb.h>

But with the previous toolchain (same sysroot & Qt sources) it succeeds:

/home/nick/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ -c -march=armv8-a -mtune=cortex-a53 -mfpu=crypto-neon-fp-armv8 -mfloat-abi=hard --sysroot=/home/nick/raspi/sysroot --sysroot=/home/nick/raspi/sysroot -O2 -std=gnu++11 -w -fPIC  -I. -I/media/nick/CrossCompile/raspi/qt-everywhere-src-5.11.2/qtbase/mkspecs/devices/linux-rasp-pi3-g++ -o main.o main.cpp
/home/nick/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ -mfloat-abi=hard --sysroot=/home/nick/raspi/sysroot --sysroot=/home/nick/raspi/sysroot -Wl,-O1 -Wl,-rpath-link,/home/nick/raspi/sysroot/opt/vc/lib -Wl,-rpath-link,/home/nick/raspi/sysroot/usr/lib/arm-linux-gnueabihf -Wl,-rpath-link,/home/nick/raspi/sysroot/lib/arm-linux-gnueabihf -o xcb main.o   -lxcb

I don't understand why the newer compiler can't find the xcb.header from sysroot while the older compiler can.

Here's the g++ -v output of both compilers:

nick@ubuntu:~/raspi$ tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++ -v
Using built-in specs.
COLLECT_GCC=tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/media/nick/CrossCompile/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../libexec/gcc/arm-linux-gnueabihf/4.8.3/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: /home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/.build/src/gcc-linaro-4.8-2014.03/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=arm-linux-gnueabihf --prefix=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install --with-sysroot=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-languages=c,c++,fortran --disable-multilib --enable-multiarch --with-arch=armv6 --with-tune=arm1176jz-s --with-fpu=vfp --with-float=hard --with-pkgversion='crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03' --with-bugurl=https://bugs.launchpad.net/gcc-linaro --enable-__cxa_atexit --enable-libmudflap --enable-libgomp --enable-libssp --with-gmp=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpfr=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-mpc=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-isl=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-cloog=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --with-libelf=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/.build/arm-linux-gnueabihf/build/static --enable-threads=posix --disable-libstdcxx-pch --enable-linker-build-id --enable-plugin --enable-gold --with-local-prefix=/home/zhehe01/work/bzr/pi-build/builds/arm-linux-gnueabihf-raspbian-linux/install/arm-linux-gnueabihf/libc --enable-c99 --enable-long-long --with-float=hard
Thread model: posix
gcc version 4.8.3 20140303 (prerelease) (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03)

and

nick@ubuntu:~/raspi$ /opt/cross-pi-gcc/bin/arm-linux-gnueabihf-g++ -v
Using built-in specs.
COLLECT_GCC=/opt/cross-pi-gcc/bin/arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/opt/cross-pi-gcc/libexec/gcc/arm-linux-gnueabihf/8.3.0/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../gcc-8.3.0/configure --prefix=/opt/cross-pi-gcc --target=arm-linux-gnueabihf --enable-languages=c,c++,fortran --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-multilib
Thread model: posix
gcc version 8.3.0 (GCC)

What could cause the later compiler to not find the xcb headers?

Improve this question
5
  • Have you tried to explicitly specify the path to xcb.h?
    – Dmitry Grigoryev
    Dec 2, 2019 at 10:16
  • No I haven't, but the only change is the toolchain. The sysroot and Qt sources are the same and xcb/xcb.h exists in the expected location. Everything else compiles successfully. I've sinced switched to Windows hosted cross-compilation and have moved on, but still confused why this would happen.
    – NickD2039
    Dec 5, 2019 at 5:31
  • Well, if you're not interested in investigating this, I guess nobody else is either.
    – Dmitry Grigoryev
    Dec 5, 2019 at 11:25
  • @Dmitry - Thanks. My question is why would a different toolchain not pick up XCB whereas the first toolchain did. If I was to 'fix' the problem by explicitly specifying the path then I'd still be none the wiser as to the difference between the toolchains.
    – NickD2039
    Dec 6, 2019 at 4:44
  • I didn't suggest this as a fix, but as a test to confirm that it's indeed a path problem. Anyway, I'm glad you have figured that out.
    – Dmitry Grigoryev
    Dec 6, 2019 at 12:18

1 Answer 1

Reset to default
0

You can examine the default search paths by issuing this command to gcc:

gcc -xc -E -v -

So comparing the output that gcc command under the two toolchains I can see that the newer one is lacking some default include directories.

Older toolchain:

...
#include "..." search starts here:
#include <...> search starts here:
 /media/nick/CrossCompile/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/include
 /media/nick/CrossCompile/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/include-fixed
 /media/nick/CrossCompile/raspi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/include
 /home/nick/raspi/sysroot/usr/include/.
 /home/nick/raspi/sysroot/usr/include/arm-linux-gnueabihf
End of search list.

Later toolchain:

...
#include "..." search starts here:
#include <...> search starts here:
 /opt/cross-pi-gcc/lib/gcc/arm-linux-gnueabihf/8.3.0/include
 /opt/cross-pi-gcc/lib/gcc/arm-linux-gnueabihf/8.3.0/include-fixed
 /opt/cross-pi-gcc/lib/gcc/arm-linux-gnueabihf/8.3.0/../../../../arm-linux-gnueabihf/include
End of search list.

So the later toolchain is not picking up /usr/include which is where xcb/xcb.h lives.

Improve this answer
1
  • I’m new to qt and cross compiling, and I believe I’m running into this same problem (was following a similar guide to the one you linked). How did you get the toolchain/gcc to search the missing paths?
    – Michael Cheng
    Dec 21, 2020 at 6:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.