Android installs missing gcc_64 directory

[tumic0]

If you install Android Qt6 builds on linux like (this is how the github action works): python3 -m aqt install 6.3.0 linux android android_armv7 -O /home/runner/work/GPXSee/Qt the resulting Qt installation is broken as it is missing the gcc_64 directory which contains the actual Qt binaries (in android_armv7 there are only symlinks) like qmake.

As a result, qmake-based builds are not possible with Qt installed using aqtinstall.

[tumic0]

Ok, so there is a workaround to install both the desktop Qt and the Android Qt using aqtinstall, but this is:

1. questionable, if this is the desired behaviour
2. nowhere documented (if you install Android Qt like described in aqtinstall documentation, qmake-based builds will not work)

[miurahr]

Here is what we do before call `install-qt`` for android on CI test.

https://github.com/miurahr/aqtinstall/blob/d6aa879d7f9477512b35dc05c76069c73f8a5f21/ci/steps.yml#L53-L59

aqtinstall is an unofficial simple tool to download and extract package which are specified by user who knows how to do. Because a genuine installer (internal) behavior is undocumented in official Qt site, all the documentation for aqtinstall can be filled only by user contributions.

@tumic0 you may be first person who can contribute to documentation for android packages.

[tumic0]

Ok, so you do the same (install the desktop version before the Android version) in your CI test. But the question, whether it is something one would expect/want stays. I would rather see aqtinstall to install a complete/working Qt setup when used to install Qt for the Android target than having to go through the documentation to find the required "hack".

you may be first person who can contribute to documentation for android packages.

I do evidently not have a better knowledge than you have as you already know, that the Android aqtinstall (the official installer works fine) does not work without further actions, it's just missing in the documentation. And here it is much easier for you, who knows how the doc works/is generated to add a sentence like: "You must also install the platform's desktop Qt version for the Android version to work properly" then for me to find it all out. Moreover, I have already learned it the hard way, so being written in the doc is of no use for me anymore... ;-)

[ddalcino]

I agree that this info should be mentioned in the documentation.

If you're expecting this dependency to be installed automatically, I think the proper place to discuss that is #332. The android versions of Qt all list the desktop version of Qt as a dependency in the Updates.xml file; this is something that aqt doesn't handle yet, but plans to in the future.

There is a potential issue with the way aqt patches android Qt files on Windows; I think it assumes that you have installed Qt for mingw 8.1. I think this will need to change at some point because that architecture doesn't exist for several versions of Qt 6.

[miurahr]

@tumic0 Here is a XML metadata file at download.qt.io https://download.qt.io/online/qtsdkrepository/linux_x64/android/qt6_630_armv7/Updates.xml

I cannot find any dependency for gcc_64 binary in the definition from Qt distribution site. All the specified binaries in the XML file are end with ARMv7.7z in the case.

So even when #332 resolved, this may not be resolved and may need some tweaks.

@ddalcino

There is a potential issue with the way aqt patches android Qt files on Windows; I think it assumes that you have installed Qt for mingw 8.1. I think this will need to change at some point because that architecture doesn't exist for several versions of Qt 6.

I agree that this is another issue we should see.

[ddalcino]

I cannot find any dependency for gcc_64 binary in the definition from Qt distribution site. All the specified binaries in the XML file are end with ARMv7.7z in the case.

So even when #332 resolved, this may not be resolved and may need some tweaks.

Apologies; I thought I saw it in one of the <Dependencies> tags, and I can't find it now. Clearly, I was wrong. It sounds like this issue is unrelated to #332.

I think I agree with @tumic0 that aqt should be able to install the required desktop version of Qt automatically, but I have questions about how this feature should work.

1. Should aqt install-qt linux android 6.3.0 also install the desktop gcc_64 version of 6.3.0 automatically, or should a flag be required to trigger that behavior? a. What should the flag be called? b. Should the user be able to pass other options to the desktop Qt installation, like --archives and --modules?
2. For installations on Windows, how should we choose which architecture of desktop Qt to install by default? I think it would make sense to just automatically choose one of the available mingw architectures, but there are often several mingw choices available. For Qt 5.12-5.15, you can usually choose either 64 or 32 bit mingw, and I thought there were a few versions that let you choose between mingw 7.3 and 8.1 (I cannot find them now).

[emericg]

I've had the same problem for a while, building softwares on GitHub CI using aqtinstall to get the latest Qt versions (great tool, thanks guys). Now using the workaround mentioned here and in other threads (installing desktop then mobile version), it works well enough. But today I had to build Qt modules (both patched and unofficial modules) before building my own software, and I came across a new problem.

In the file android_arm64_v8a/lib/cmake/Qt6/ there are paths to my desktop install of Qt set in stone, but not in GitHub CI using aqtinstall:

# Set up QT_HOST_PATH and do sanity checks.
# A host path is required when cross-compiling but optional when doing a native build.
# Requiredness can be overridden via variable.
if(DEFINED QT_REQUIRE_HOST_PATH_CHECK)
    set(__qt_toolchain_host_path_required "${QT_REQUIRE_HOST_PATH_CHECK}")
else()
    set(__qt_toolchain_host_path_required "TRUE")
endif()
set(__qt_toolchain_initial_qt_host_path
    "/home/emeric/Dev/tools/Qt/6.3.1/gcc_64")
set(__qt_toolchain_initial_qt_host_path_cmake_dir
    "/home/emeric/Dev/tools/Qt/6.3.1/gcc_64/lib/cmake")

This is easy enough to bypass by using a QT_HOST_PATH environment variable once you understand the problem, but still. If both versions would be installed at the same time, that variable might have been set automatically?

1/ The Android and iOS versions cannot be used without their desktop counterpart right? So I fail to see why they should be installed separately (even without using a flag, it should probably default to the most common desktop arch) 2/ But yeah I understand that a some kind of indication might be needed anyway. Why not use the name of the directory (the equivalent of gcc_64, I don't now if that has a name) like host=gcc_64.

[ddalcino]

In the file android_arm64_v8a/lib/cmake/Qt6/ there are paths to my desktop install of Qt set in stone, but not in GitHub CI using aqtinstall:

Yes, there are probably a lot of these. The Updater module does some work to patch a small subset of these files, but there are a lot more that we don't know about. Contributions are welcome!

I have a PR at #540 that should help with this. I will make sure that the path to the desktop Qt install is available in the Updater module.

1/ The Android and iOS versions cannot be used without their desktop counterpart right? So I fail to see why they should be installed separately (even without using a flag, it should probably default to the most common desktop arch)

Automatically installing a desktop version of Qt is a breaking change for the UI. All of our users who are currently using aqt to build android/ios apps are currently installing the desktop version separately. If we start installing the desktop version automatically, we will cause a lot of CI jobs to download hundreds of extra MBs and waste a lot of CPU cycles unnecessarily; that will cost our users real money. I would rather not do that. The new feature in #540 will be opt-in only, and it will emit a warning if you don't use it when you probably should.

You are right that this should probably be an opt-out feature, and that aqt should just "do the right thing" automatically when you don't set any flags. Since this would be a breaking change, it has to wait for version 3 according to semantic versioning rules.

2/ But yeah I understand that a some kind of indication might be needed anyway. Why not use the name of the directory (the equivalent of gcc_64, I don't now if that has a name) like host=gcc_64.

I was asking about the specific case on Windows, where there are multiple architectures available (mingw73_32, mingw81_64, etc). #540 attempts to just pick the newest version available. If the user wants a different version, they can install it themselves.

[emericg]

If we start installing the desktop version automatically, we will cause a lot of CI jobs to download hundreds of extra MBs and waste a lot of CPU cycles unnecessarily; that will cost our users real money. I would rather not do that.

I understand

I was asking about the specific case on Windows, where there are multiple architectures available (mingw73_32, mingw81_64, etc). https://github.com/miurahr/aqtinstall/pull/540 attempts to just pick the newest version available. If the user wants a different version, they can install it themselves.

The desktop installation is there just for the tools? Picking the newest mingw installation should be ok. But I don't cross compile on Windows so I don't really know.

I'll keep an eye on #540 then, thank you for your work!