Why did you deprecate GCC? about ndk HOT 31 CLOSED

I can give you my opinions: Clang is faster while compiling source code; has better support for c++14/c++17 and since it is designed primarily as library, it can be used from IDEs like Android Studio to perform static code analysis, refactoring and code completion.

Besides that, Clang is under more permissive open source licence, unlike GCC, which is under GPL. Thus, it is easier to make commercial clang clones which give better support for certain CPU architectures. Also, clang works better with libc++ than GCC, and many native code developers tend to use libc++ because, when compared to GNU stdc++, it has better support for c++14/c++17 STL features and is under permissive BSD-like licence - this makes it possible to use c++14/c++17 features in commercial android apps, like games. GNU stdc++ is under LGPLv3, which makes it impossible to use in commercial apps (yes, stdc++ has special exception for LGPL which allows usage in commercial apps, provided that you do not modify it - but this makes commercial app development very uncomfortable).

I believe that issues like #21 and #9 will be solved soon.

from ndk.

Licensing actually did not play a significant part in the decision. The other reasons that @DoDoENT mentioned are correct though (yes, GCC 5.x supports C++14, but new features definitely do happen more quickly in clang). The biggest reasons for why we made this decision actually haven't been mentioned though:

So, GCC was good to build Android for 10 years and now, suddenly is not, and google must ditch it.

Things change. GCC isn't good for Android any more because GCC doesn't provide the same security features that Clang does (and when it does, it provides them much later).

An incomplete list of why the platform switched to clang:

• We make extensive use of integer overflow sanitizers in shipping code to prevent issues like stagefright from recurring
• Address sanitizer and libfuzzer are used widely in testing
• Clang's better diagnostics catch a ton of bugs that GCC does not
• Control flow integrity and safe stacks are being deployed (are deployed?) for even more exploit mitigation.

The fact is that we have significant reason to invest in clang, and splitting effort across maintaining two compilers makes both of them worse.

As it stands now, both compilers are fairly comparable in terms of performance and code size. #21 points at code size increases for armeabi-v7a. That is not always the case, and for every other architecture we actually see smaller code. From some analysis I did when we made this decision for the platform:

It seems our 32-bit ARM devices are typically 1MB larger (out of 600MB-900MB total), whereas volantis is slightly smaller, and fugu is 15MB smaller. Strangely, sprout_b is also slightly smaller.

I think the ARM32 numbers are small enough to not bother anyone, especially given that it looks like it will be a win for the new devices since they're aarch64.

All the comparisons we did showed that Clang and GCC were pretty much equivalent quality when it came to the code they produced. Yes, sometimes we find cases where GCC is faster, but we also find cases where Clang is faster. As an example, we saw a 20% performance improvement in the ART interpreter when we switched to clang.

from ndk.

@DanAlbert @stephenhines : I understand that you don't have resources to maintain it (which sounds like a joke to me ... who could imagine that google can't afford to pay a gcc hacker to maintain it), but why don't you accept community contributions?

@jcelerier @DoDoENT My feeling is that the whole story is not about which compiler is better for google customers, instead is about control and what is better for Google. Google is one of the most GPL haters out there (or at least this is how it looks like), and an BDS like license is more "suitable" for them... Why? Well because the BSD licence allows the Google to choose what (or if) they share back with the community. Again, this is my personal feeling...

from ndk.

You mean that latest clang has better support than gcc 4.9, right? Because AFAIK gcc 5.x has full C++14 support.

Regarding the licenses IMHO you get it wrong. Personally I prefer GPL because it doesn't allow closed source clones, IMHO is fair to give something when you take so much.
GNU libstdc++ is GPL (NOT LGPL) but the special exception that you've mentioned allows everyone to freely use it and also to CHANGE IT as long as the changes made to libstdc++ are made public under GPL. IMHO it is quite stupid to keep these changes for yourself and not to upstream them, because you'll need to maintain them which is not for free.

Least but not last, let's not forget that Google switched to OpenJDK, which is GPL, therefore IMHO the licensing issue doesn't stand.

So, GCC was good to build Android for 10 years and now, suddenly is not, and google must ditch it.

from ndk.

@stephenhines : we aren't free to use "whatever compiler we like" : the choice is between an old GCC and a new Clang. If at least there was a procedure somewhere to build a more recent GCC that works with the android ndk it would be fine.

Besides, as of today, up-to-date GCC still mostly runs circles around Clang in terms of produced code performance: https://www.phoronix.com/scan.php?page=article&item=gcc-clang-eoy2017&num=4

This has a direct effect on the battery consumption of the software.

from ndk.

Even more, GCC 6.2 has now faster compile times than clang, while still producing more optimised binary. Here are benchmarks from Phoronix (see page 3).

from ndk.

Regarding

new features definitely do happen more quickly in clang

As of today, that is not true : GCC has better C++17 compiler support than clang...

http://en.cppreference.com/w/cpp/compiler_support

from ndk.

Thanks for the updates on GCC. We still have no plans to continue maintaining it, but I am glad that others in the community are still working on it.

from ndk.

As of today, that is not true : GCC has better C++17 compiler support than clang...

http://en.cppreference.com/w/cpp/compiler_support

The majority of those features are not in any released version of GCC. Clang hasn't finished it's release cycle either. You have more C++17 with our current Clang than you would with a current GCC, and odds are Clang will close the current gap before 4.0 is done.

Keep in mind my comment above. We have many other reasons to choose Clang, and do not have the resources to pursue both.

from ndk.

If at least there was a procedure somewhere to build a more recent GCC that works with the android ndk it would be fine.

https://android.googlesource.com/toolchain/gcc/+/master/README.md

from ndk.

Using Clang on Windows is the same as using Clang on Linux or Darwin when it comes to the NDK. The NDK compilers are not intended to compile for Windows.

from ndk.

The answer to #26 is use Clang. Not GCC.
In case anyone was wondering.
And using Clang on Windows 10 has zero tutorials.
There is one on the official website for Clang, its like a PCI-e 1.0 port for a PCI-e 4.0 device.

from ndk.

This is problematic as the Android’s kernel still requires gcc.

Pixels have been shipping with clang-built kernels for ~3 years now.

from ndk.

Until standard Linux kernels can be built without extra patches, keeping a working GCC around is pretty valuable. Looks like Google is aggressively pushing Qualcomm off of 3.18, but until every device is off 3.18 it needs to stay.

Really awful reason, but it is an issue.

from ndk.

@jmgao but Samsung kernels and other manufacturers still require gcc 4.9 and in fact their official binaries use gcc 4.9.

Pixels have been shipping with clang-built kernels for ~3 years now.

(also as someone who tend to favor performance, I’m not kind to run the kernel code as bytecode under a small jit compiler). And gcc doesn’t care about preserving the overall form of the original code (debugging vs performance of course).

But does the android kernel even requires an android compiler?

from ndk.

It's actually part of the Android CDD that new devices ship with Clang-built kernels to ensure all relevant security features (CFI and more going forward) are enabled.

from ndk.

I just gave my opinions - let the NDK guys give theirs. I think the tooling support in clang is probably the main reason for switching to it.

from ndk.

@stephenhines might want to add more to this, but I think I covered most of the bases.

from ndk.

BTW, it's in Qt the Qt-for-Android Known Issues :-(
https://wiki.qt.io/Qt_for_Android_known_issues

There is a bug in GCC in the latest Android NDK, making it impossible to use it for building Qt. The bug has not been fixed yet, and it's recommended to use Android NDK r10e. NDK r15 produces applications that fail with the error message 'This application failed to start because it could not find or load the Qt platform plugin "android"'. See also the bug report.

from ndk.

The bug referred to (#67) is a GCC bug. Use Clang and you won't have a problem.

from ndk.

It's not an issue if none of our devices are using GCC for their kernels. Again, feel free to use whichever compiler you like, but we are no longer actively supporting GCC (just like I mentioned last year). https://youtu.be/6l4DtR5exwo if you want to see our talk about getting the kernel and the rest of Android over to Clang.

from ndk.

Until standard Linux kernels can be built without extra patches, keeping a working GCC around is pretty valuable.

The NDK compilers are not guaranteed to work for the kernel at all. The kernel compilers come from the prebuilts/gcc/... or prebuilts/clang/... project of the given kernel manifest project.

from ndk.

@DanAlbert It should, big companies are using it this way.

from ndk.

Thanks for the updates on GCC. We still have no plans to continue maintaining it, but I am glad that others in the community are still working on it.

This is problematic as the Android’s kernel still requires gcc.

from ndk.

That's not how LLVM works. The bytecode is just an IR. It compiles down to machine code just like GCC does. Sometimes it performs better, sometimes it performs worse.

from ndk.

@expnkx please share your build and patched source tree!

from ndk.

Please find another forum for this conversation. Nothing wrong with using your own toolchains, but it'd be better if you created your own project for that discussion.

from ndk.

evil decision.

from ndk.

Armv9 (Galaxy S22 on snapdragon) is only supported on gcc for now. So that is funny.

Searching for armv9 in clang/test/Preprocessor/aarch64-target-features.c would show you that armv9 is indeed supported in Clang (and has been so for quite some time actually). I'm not sure that I see the relevance of armv9 for most NDK users right now, however, considering that the vast majority of aarch64 devices in use are going to be armv8 only, so you wouldn't necessarily want to use this ABI even for specific libraries to dynamically load on certain devices only.

from ndk.

Still here, still mad about this 😠

from ndk.

Locking the thread as it stopped being constructive a very long time ago. If you have an issue with clang (a fixable one, not just "it isn't GCC"), file a bug.

from ndk.