[Development] The sorry state of the Qt6 cross compile experience

Bogdan Vatra bogdan.vatra at kdab.com
Wed Feb 24 09:30:12 CET 2021


În ziua de marți, 23 februarie 2021, la 22:06:55 EET, Joerg Bornemann a scris:
> On 2/23/21 12:27 PM, BogDan Vatra via Development wrote:
> OK, biting.
> > - first and foremost, we need to waste time to **fully** build and install
> > it for host platform (desktop).
> No, you don't need a full build. You need the tools that are called by
> the build system. The support for creating a "minimal desktop" build
> could be better, sure. But you're one of few affected people.

Let's check some numbers:
bogdan at debian:~/Qt/5.12.10/android_arm64_v8a$ du -sh .
357M    .
bogdan at debian:~/Qt/5.12.10/android_arm64_v8a/include$ du -sh .
91M     .
So, before we had all ABIs in one place, a single ABI had over 350Mb and  only 
the headers were +25%. Of course there are many other common files not only the 

bogdan at debian:~/Qt/5.15.2/android$ du -sh .
656M    .
5.15.2 has all 4 ABIs in one place (also a few extra modules than 5.12.0).
The conclusion is: having all the ABIs in one place reduced the SDK with +50%! 
656M < 357M * 4

Now let's check 6.0.1. I choose to install only android, and this is what I 
bogdan at debian:~/Qt/6.0.1$ ls
android_arm64_v8a  android_armv7  android_x86  android_x86_64  gcc_64  
bogdan at debian:~/Qt/6.0.1$ du -sh .
1,4G    .
The conclusion is: 6.0.1 has less than half of the 5.15.2 Qt modules, but it 
has more than twice the size of 5.15.2 for Android.

Let's see how big are the tools
bogdan at debian:~/Qt/6.0.1/gcc_64/bin$ du -sh .
97M     .

So, for 100M, you've added +700M.

Do you still believe that I'm one of the few affected by this?
Don't you think that everyone who's using cross compiling is affected?

>  >  Yeah, I know that this was "decided" before TQC
>  > 
>  > switched, overnight, to cmake, but let's face it, it's a BS needed to
> cover
>  > the fact that cmake can't build more than one platform at once.
> Let's face it. It's a good thing to not compile the same set of tools
> over and over again, and it simplifies the build very much.

It's a good thing when is done right, check the numbers above. Right now is 
broken, there is no way to install only the host tools. As long as the bug 
report has a P2 priority, I'll not hold my breath to see it fixed any time 
soon, for sure not in 6.1 or in 6.2....

> > - the cross build installation is broken, instead to copy the tools from
> > the QT_HOST_TOOLS folder,  it creates some scripts that has hardcoded
> > paths to QT_HOST_TOOLS which runs the scripts from QT_HOST_TOOLS folder.
> > Of course this makes the installation unusable on another computer. Even
> > the "lib/cmake/Qt6/ qt.toolchain.cmake" contains hardcoded paths...
> Right. The Qt5 qmake build never had any hard-coded paths. Try again.

Well qmake was smart enough to replace the hard-coded paths with the ones 
found in qt.conf....
Just to be clear, I'm not the qmake advocate, I'm not saying that qmake is 
better than cmake for all the projects out there, I'm using cmake myself in 
many of my projects. What I'm saying is that qmake being specifically crafted 
for Qt was better than cmake to build Qt.

> > - there is no way to have a standalone cross build installation, we always
> > need to ship the whole desktop installation as well (also patch all the
> > files from cross installation).
> Do interpret this correctly as the second attempt in your mail to kindly
> suggest better support for a minimal desktop build?
> > - android cross compilation is so crippled now.  In Qt 5.x times, we used
> > to have a nice multi ABI build which built all the android ABIs in one go
> > and it created a unified Qt SDK for all these ABIs (same as the Android
> > NDK). In Qt 6, that work was trashed... for the same reason: cmake can't
> > handle multiple platforms at once...
> That's right. We're lacking support for multi-ABI that was hacked into
> the Qt build where we run configure tests for one random architecture
> and use those configure results for all other architectures.
> I consider this a good thing.

How can be a good thing to:
- have twice the size of the Andorid sdk on disk for less modules
- not being able to bundle multiple ABIs in the same package anymore

> > - android cross compilation in Qt 6 takes more time to build one ABI  with
> > less Qt modules than in Qt5 to build all ABIs and all modules...
> And your thorough analysis of the problem is "CMake is BS"?

If you check my email again, you'll see that I didn't said that "CMake is BS", 
I said that the host tools is a BS, and I'll keep believing that until I'll 
see a real benefit.
Having only host tools built without being able to install them makes them 
useless. Even after you'll fix the installation, they are still useless as long 
as the QtSDK will not share other common resources (i.e. headers).
If QtSDK will install only the specific parts of a platform (something like 
Android NDK or debian[1]), then I'll see a real benefit.


[1] Debian has almost perfect cross compilation support, you can install qt 
libs for armhf, arm64, etc. alongside with your x86_64 ones and it will use 
the same headers and the same common resources. I'm keep giving Debian as an 
example, because that's the distribution that I know the best as I'm using it 

More information about the Development mailing list