Qt 6.8.1 cross-compilation

OscarZero

I'm developing on an ARM host (Ubuntu 24.10 VM on a MacBook Pro) and I am trying to cross-compile QtBase 6.8.1 for a x86 target. The target device is very slow and resource limited, hence the cross-compilation aim.

My understanding is that I need to first build from source for the host, which I've done into /home/foo/qt/arm/ and I can build a Qt example program against that and run it on the host. So far so good.

I've installed a x86 toolchain on the ARM host, and I'm able to compile C++ source files on the ARM host for the x86 target, and execute those binaries on the x86 target.

Next, I'm trying to build Qt for the x86 target into /home/foo/qt/x86/ but the various approaches I've tried end in failure.

According to https://doc.qt.io/qt-6/configure-options.html I'm meant to use the -external-hostbindir option to point to the host installation. So I'm doing this:

CC=x86_64-linux-gnu-gcc-14 CXX=x86_64-linux-gnu-g++-14 ../qtbase-everywhere-src-6.8.1/configure -external-hostbindir /home/foo/qt/arm/libexec -prefix /home/foo/qt/x86/ -no-opengl

But it looks like there's no such -external-hostbindir option, so maybe the above URL is incorrect? Based on another reference I tried this:

CC=x86_64-linux-gnu-gcc-14 CXX=x86_64-linux-gnu-g++-14 ../qtbase-everywhere-src-6.8.1/configure -prefix /home/foo/qt/x86/ -no-opengl -qt-host-path /home/foo/qt/arm

The configuration succeeds but the build fails when it tries to link libQt6Core.so.6.8.1 using objects of the wrong architecture type, so the command is probably still not correct.

Am I doing something wrong, or is cross-compilation of Qt6 not supported?

jsulm

@OscarZero You need to tell the platform to build for using -device parameter (see https://doc.qt.io/qt-6/configure-options.html).

OscarZero

I tried the -device parameter, but I'm not sure how to use it.

The parameter value seems to correspond to files in mkspecs/devices/ but I can't see any entry there explicitly for x86, so I tried "-device linux-generic-g++" but it still fails with the same problem I mentioned earlier. I also tried with "-device linux-nuc-g++" (figuring that's similar to the actual target), still no luck.