Supported NDK versions

[Elv1313 .]

Hi,

Good timing, I hit that bump yesterday. Some of my app dependencies no
longer compile in GCC4.9 and I wondered the same thing. After quickly
trying to "just rebuild the SDK with llvm" I ran into some KF5
Bionic-C compilation issues and ended up just patching back support
for GCC 4.9. However it is unsustainable and has you point out, GCC in
Android has no future, and more importantly, no present either. I
believe Qt6 will also not even attempt to compile on GCC 4.9 and
require full C++14, which is a good thing. We have to move away from
it soon-ish or it will start to becomes harder and harder to get KF5
apps using 3rd party C++ libraries to use the KDE SDK for Android as
more projects adopt the Modern C++ style.

I understand some members of the community may dislike LLVM. I am not
among them, I think a compiler designed as a set of libraries with
focus on tooling is a far superior approach than a giant command line
+ output text parsing. However I can see the "but free software!"
narrative and respect it. A better comparison for this argument is
that we support MSVC too. Another little advantage by moving to LLVM
for the Android NDK is that it will simplify compiling KF5 on macOS
with the *default toolset* (yes I know about using homebrew to install
GCC, but that's not what XCode and QtCreator do). In this case it
isn't really a choice anyway. Google decided to kill off GCC across
their product line and other vendors (Qt) abided to the mighty one.

It isn't that big of a problem anyway. Manually downloading the NDK,
compiling Qt for Android and then the frameworks on top usually works
beside the minor bionic issues mentioned above.

Best regards,
Emmanuel Lepage

On Thu, 10 Jan 2019 at 15:34, Volker Krause <vkrause at kde.org> wrote:
>
> Hi,
>
> with NDK 17 GCC got deprecated, with 18 (from Sep 2018) it even got entirely
> removed, and with it the corresponding C++ STL libs. And the current Qt SDK
> (5.12) only ships with clang-based binaries. Do we still want to support GCC-
> based NDKs? If so for how long? If no, does it make sense to make a hard cut
> now, and switch everything to the newer NDKs and the Clang-based toolchain?
>
> I'm wondering as we are hitting limits with the wide NDK and SDK range we
> currently try to support, e.g.
> https://phabricator.kde.org/R1007:3c86b3900aafa374389dee74ec83ae17488d521d is
> needed to build with NDK 18/SDK 28 and Qt 5.12, but it breaks binary factory
> and any other older setup.
>
> Note that this is only about the compile-time requirements, this has no effect
> on still supporting older API levels for the resulting apps at runtime, that
> we definitely want to keep.
>
> Regards,
> Volker