@m-kuhn Elapsed time to handle qtbase:x64-android: 4.2 min

qtbase 6.7 silently overrides toolchain API level 21 with actual API level 23.
Some downstream errors are related to API level 21 again, e.g. kdsoap.

qtbase also selects ANDROID_STL=c++_shared despite VCPKG_CRT_LINKAGE=static.
Eventually leading to confusion downstream, and probably also with dependencies.

FYI, #42165 changes the Docker base image for Android to 24.04 "Noble".

FYI, #42165 changes the Docker base image for Android to 24.04 "Noble".

Fine, but there is not much impact on Android.

Can you add ruby now, as in the linux image? Some ports do vcpkg_find_acquire_program(RUBY).

(We might also use openjdk from the system packages.)

qtbase and gdal passing now 🎉

• qtwayland:x64-linux is needed as a dependency (default-features woes), but fails due to the docker image lacking a number dev packages from the distro.
• sdformat ports need ruby distro package.
• qmake-based ports fail due to qmake CC/CXX not being absolute path. And possibly additional qmake var/flags issues (sysroot)
• msquic stumbles over the vendored openssl fork which inherits openssl's toolchain injection barriers.
• boost found a new excluded dedendency. Dynamic CRT linkage enables new things...

I suggest to continue with moving vcpkg android CI to this configuration. Probably using new triplets arm64-android-28 etc.

Tagging with vm-update so I remember to mint you a new Docker image with the changes here after #42749

Tagging with vm-update so I remember to mint you a new Docker image with the changes here after #42749

Oops, I forgot anyway. I blame getting COVID that week :( . Doing patch tuesday stuff for this month now and will look at minting one of these for you this week.

No problem, I probably need a moment to sort the commits. Xmas wasn't enough time for that.

What also needs to be discussed:

• Can we move to a more modern deployment target aka API level? If yes, which triplet names?
• Can we move to dynamic CRT linkage?

Cf. https://github.com/microsoft/vcpkg/pull/42080/files#r1836012959

@JonLiu1993 @LilyWangLL please review.

🙏 thanks @dg0yt !

Look, it was a simple PR!
(No, really, look where we started, #35845. Different NDK, static CRT linkage, whatever...)

Thanks @BillyONeal and team too for improving the base!

I'm not completely sure but the new vcpkg_replace_string on qmake may have broken some mac-arm64 build (see #45793) in some cases. At least this is the only recent change I see around this error, interestingly enough.

Edit: okay this patch is fine and actually revealed an issue on my side where VCPKG_HOST_TRIPLET gets automatically set to arm64-osx while I'm really targetting arm64-osx-release and the difference makes it think it's cross-compiling.