New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why did you deprecate GCC? #26

Closed
bog-dan-ro opened this Issue Mar 17, 2016 · 20 comments

Comments

Projects
None yet
9 participants
@bog-dan-ro

bog-dan-ro commented Mar 17, 2016

Is it something wrong with GCC 5.x or upcoming 6 on Android that made you to take this decision?
I think is not a good idea to ditch gcc as long as clang still have some issues e.g. #9, #21.
IMHO having both will not hurt anyone.

@DoDoENT

This comment has been minimized.

Show comment
Hide comment
@DoDoENT

DoDoENT Mar 17, 2016

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.

DoDoENT commented Mar 17, 2016

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.

@bog-dan-ro

This comment has been minimized.

Show comment
Hide comment
@bog-dan-ro

bog-dan-ro Mar 17, 2016

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.

bog-dan-ro commented Mar 17, 2016

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.

@DoDoENT

This comment has been minimized.

Show comment
Hide comment
@DoDoENT

DoDoENT Mar 17, 2016

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.

DoDoENT commented Mar 17, 2016

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.

@DanAlbert

This comment has been minimized.

Show comment
Hide comment
@DanAlbert

DanAlbert Mar 17, 2016

Member

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.

Member

DanAlbert commented Mar 17, 2016

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.

@DanAlbert DanAlbert closed this Mar 17, 2016

@DanAlbert

This comment has been minimized.

Show comment
Hide comment
@DanAlbert

DanAlbert Mar 17, 2016

Member

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

Member

DanAlbert commented Mar 17, 2016

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

@jcelerier

This comment has been minimized.

Show comment
Hide comment
@jcelerier

jcelerier Dec 15, 2016

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

jcelerier commented Dec 15, 2016

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

@DoDoENT

This comment has been minimized.

Show comment
Hide comment
@DoDoENT

DoDoENT Dec 15, 2016

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).

DoDoENT commented Dec 15, 2016

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).

@stephenhines

This comment has been minimized.

Show comment
Hide comment
@stephenhines

stephenhines Dec 15, 2016

Contributor

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.

Contributor

stephenhines commented Dec 15, 2016

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.

@DanAlbert

This comment has been minimized.

Show comment
Hide comment
@DanAlbert

DanAlbert Dec 15, 2016

Member

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.

Member

DanAlbert commented Dec 15, 2016

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.

@bog-dan-ro

This comment has been minimized.

Show comment
Hide comment
@bog-dan-ro

bog-dan-ro Jan 6, 2017

@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...

bog-dan-ro commented Jan 6, 2017

@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...

@guruz

This comment has been minimized.

Show comment
Hide comment
@guruz

guruz Nov 15, 2017

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.

guruz commented Nov 15, 2017

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.

@DanAlbert

This comment has been minimized.

Show comment
Hide comment
@DanAlbert

DanAlbert Nov 15, 2017

Member

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

Member

DanAlbert commented Nov 15, 2017

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

@ehem

This comment has been minimized.

Show comment
Hide comment
@ehem

ehem Dec 28, 2017

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.

ehem commented Dec 28, 2017

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.

@stephenhines

This comment has been minimized.

Show comment
Hide comment
@stephenhines

stephenhines Dec 28, 2017

Contributor

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.

Contributor

stephenhines commented Dec 28, 2017

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.

@jcelerier

This comment has been minimized.

Show comment
Hide comment
@jcelerier

jcelerier Dec 28, 2017

@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.

jcelerier commented Dec 28, 2017

@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.

@DanAlbert

This comment has been minimized.

Show comment
Hide comment
@DanAlbert

DanAlbert Jan 2, 2018

Member

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.

Member

DanAlbert commented Jan 2, 2018

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.

@DanAlbert

This comment has been minimized.

Show comment
Hide comment
@DanAlbert

DanAlbert Jan 2, 2018

Member

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

Member

DanAlbert commented Jan 2, 2018

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

@android-ndk android-ndk deleted a comment from Raulvo Feb 3, 2018

@snow8gaia

This comment has been minimized.

Show comment
Hide comment
@snow8gaia

snow8gaia Mar 26, 2018

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.

snow8gaia commented Mar 26, 2018

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.

@DanAlbert

This comment has been minimized.

Show comment
Hide comment
@DanAlbert

DanAlbert Mar 26, 2018

Member

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.

Member

DanAlbert commented Mar 26, 2018

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.

@vczh

This comment has been minimized.

Show comment
Hide comment
@vczh

vczh May 1, 2018

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

vczh commented May 1, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment