
Android NDK: GCC is now deprecated, everyone should be switching to Clang - ingve
https://android.googlesource.com/platform/ndk.git/+/master/CHANGELOG.md
======
JoshTriplett
The sad thing is that "easy to link and embed" and "permissive license" really
didn't have to go together like they did in LLVM.

GCC _could_ have provided a library that made it easy to do code generation or
compiler development. That library could still have used the GPL, so that only
Free Software could use it. Some of the work that has happened around LLVM
wouldn't have happened around such a library, but some of it would have. (GCC
has much more recently started down the "plugin" route, but too little too
late.)

For instance, Swift might not have happened. But Rust may well have; a rustc
compiler under GPL would not have broken anyone's ability to use it, any more
than GCC's GPL prevents people from building proprietary software with it.

But instead, the GNU project chose to make it difficult to build any extension
to GCC outside of GCC's own codebase. So instead of having an easy-to-use
library provided by GCC under GPL, which might have furthered many of the GNU
project's goals and encouraged more Free Software compiler development, they
forced the development of an entirely separate compiler project to provide
such a library. And the people who came along to do so, since they had to
rewrite it anyway, chose to do so under a permissive license.

So, at least in hindsight, the Free Software world is worse off than it would
have been had GCC provided a library infrastructure.

~~~
djsumdog
I feel like you're missing the point of the GNU GPL. The original idea behind
the FSFs idea of open source was an ecosystem where every new development
resulted in more open and free code. We're talking about people who truly
believed in getting away from commercial software entirely. There were people
who felt that one day, Linux desktops could replace Windows and even high end
tools like Photoshop and Final Cut would have great open source replacements.

...but that never happened. Apple has tried to remove all GPL code from Mac
OS. Where GPL code exists, it's only GPLv2 (like Bash; using an ancient
version).

Even though all these companies are embracing opens source, they're embracing
only permissive licenses. They're open sourcing the underlying tech stack
while keeping all their offerings closed. If you're on Android, you are
totally locked into Google services. I've met people who tried only using
F-droid and running "open source phones" (minus the drivers of course). Their
phones sucked. One of them switched back because she was tired of writing apps
to do things she use to be able to do with the Play Store.

The dream of a GPL world where the software is free and you only pay for the
hardware, is pretty much gone. We don't have federated systems, and where we
do, no one uses them (GNU Social, Miro, Diasporia).

This isn't the open source world some of us envisioned back in the late 90s. I
personally, will keep as much of my code under GNU GPL as I can.

~~~
JoshTriplett
> I feel like you're missing the point of the GNU GPL. The original idea
> behind the FSFs idea of open source was an ecosystem where every new
> development resulted in more open and free code.

First of all, "FSF's idea of open source"? They'd rather vigorously object to
that phrasing. :)

But no, that was _exactly_ my point: I'd argue that intentionally choosing to
not allow the development of a library version of GCC, even under the GPL,
caused a net _reduction_ in the amount of Free Software in general, and
copyleft-licensed Free Software in particular, that would otherwise have been
developed.

~~~
dragonwriter
RMS -- and perhaps the FSF more generally -- seems more concerned with
preventing non-Free software, with creating Free Software as a means to that
end, than increasing the volume of Free Software.

To RMS, non-Free software isn't just worse than Free software, its a net harm
to society such that it's better to have _no_ software than to have non-Free
software. Its even often (apparently, to RMS) better to have no additional
software than to have a lot of additional Free Software and some additional
non-Free software.

~~~
JoshTriplett
I wouldn't describe the FSF's position that way (they value Free Software for
its own sake, and their goal is that all software should be Free Software),
but even if that _were_ their position, I'm arguing that their handling of GCC
and refusal to support it as a library directly motivated the creation of LLVM
and led to a scenario that better supports the creation of proprietary
software.

Providing a GCC library would have significantly lessened the motivation for
LLVM: many of the "we need a library" folks would have one, leaving just the
"we need a permissively-licensed library" folks, and the "GCC's codebase is
awful" folks. (And even some of the latter group might have worked to fix
GCC.)

That's not the _only_ thing done wrong with GCC development. The much worse
problem is that GCC doesn't really support reviewing and accepting patches;
you pretty much have to have commit access to do any significant work on GCC.

~~~
sangnoir
> I'm arguing that their handling of GCC and refusal to support it as a
> library directly motivated the creation of LLVM and led to a scenario that
> better supports the creation of proprietary software

I'm sure they are well aware of that. I don't see how they could have handled
it differently without compromising their core values. Allowing GCC to be
wrapped by proprietary bits would be unconscionable since it curtails user
freedom (to modify & improve the software).

The differences in core-beliefs between Apple and FSF are irreconcilable: the
former is pro-Tivoization and the latter is anti-Tivoization. Your stance on
Tivoization ought to be a fair indicator on which side of the fence you stand,
and no side will _ever_ be able to convince the other side: at best you can
agree to disagree.

~~~
isolate
You're either with us or against us?

------
noobermin
I'm not sure if this will stoke a flamewar, because I've never seen a
discussion here on this (might just be hanging around different articles). Is
there any technical reason to prefer clang over gcc other than ideological
reasons? I get the modular nature of llvm is useful, but is the android NDK
using this feature?

Quick google search shows clang lagging gcc in all but one test[0] at least on
Intel Broadwell. Again, what is the benefit other than permissiveness of the
license?

[0] [http://www.phoronix.com/scan.php?page=article&item=clang-
gcc...](http://www.phoronix.com/scan.php?page=article&item=clang-gcc-
broadwell&num=1) This is almost a year old, though

~~~
kevinchen
I don't know much about Android NDK, but in general, people use clang because:

\- Clear and readable diagnostics -- especially useful when debugging nasty
C++ template stuff where the type signature is a page long. (GCC is catching
up in this area)

\- Modular design -- if an IDE wants to have syntax highlighting or an
Xcode/Eclipse/IntelliJ like "fix it" feature, they can use the clang frontend
to parse the code. Also, GCC's "big ball of mud" design (iirc they do some
optimizations like constant folding in the parser) makes it harder to hack on
unless you're already pretty familiar with the codebase.

\- Less hostile community -- people have tried to clean up GCC but their
patches were rejected (see the RMS email link below)

\- Helps you with standards compliance -- clang will still compile code with
compiler-specific extensions but it has an option to output a warning. There
are some codebases that have come to rely on these behaviors so clang's
warnings can help make sure you don't end up tied to one specific compiler.

\- Personally, I like AddressSanitizer (ASan). It does similar checks as
Valgrind, but using compile-time instrumentation -- just pass in an additional
flag. Gets rid of a dependency.

~~~
jevinskie
FWIW, GCC has ASan too. [0] I'm not sure how it compares to the LLVM
implementation, I've only tried LLVM's (with good results).

Having said that, I hack on LLVM daily and would not relish having to use GCC
to the same effect. LLVM really does shine when used as a library!

[0]: [https://gcc.gnu.org/onlinedocs/gcc/Debugging-
Options.html](https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html)

~~~
haldean
ASan and UBSan are the same in the two; both the GCC and clang instrumentation
shims were contributed by Google, and the resulting instrumentation is the
same.

------
belorn
How diverse are the CPU manufacturers for android phones? The major concern
when it comes to Clang is that developers will need to buy proprietary plugins
to compile open source code that depend on proprietary features, or to have
application run in native speed.

~~~
rmstwitterbot
Requiring a license to use a compiler is straight out of RMS's (now
unfortunately prophetic) article "The Right to Read"
[http://www.gnu.org/philosophy/right-to-
read.en.html](http://www.gnu.org/philosophy/right-to-read.en.html)

Majority of Android phones out there are Qualcomm Snapdragon these days, and
for the foreseeable future as they just inked an exclusive deal with Samsung.
MediaTek SoC was already a proprietary nightmare of unreleased kernels and
toolchains except for the leaked MT6589

~~~
LukeShu
In "The Right to Read", "license" refers to a license from the state, like a
driver's license or gun license; not a license from the vendor (a copyright
license). Vendors licensing proprietary compilers isn't something that TRR
predicted--it was a common practice before GCC became dominant.

------
psibi
For someone not following the project, what's the reason for deprecation and
switch over to LLVM ?

~~~
earlz
As someone messing with LLVM a lot.. basically LLVM is where a ton of
development effort is going. GCC is a dead end it seems like. LLVM is designed
to be extended where as GCC.. well, usually doesn't really seem to have been
designed.

~~~
steve19
GCC has been designed specifically NOT to be extended.

Richard Stallman reasoned that by exposing an interface to other applications,
or allowing other applications to access or modify intermediate code/trees,
closed source proprietary applications could be built around GCC.

He was probably right ... but we all ended up with a worse compiler.

~~~
sprash
> worse compiler

Last time I checked gcc binaries beat Clang performance wise.

~~~
whateveracct
performance is far from the only or most important measure of a compiler

------
dman
I am pleasantly surprised that so many people have taken the time to read the
source code of multiple compilers and have an opinion on why one is better
than the other.

------
Ace17
Speaking of LLVM's "modular" architecture ; LLVM's architecture is so modular
that projects like the Rust compiler or Emscripten use their own modified
forks of the LLVM tree ...

What's the point in being "modular", if you can't add a backend nor a frontend
without having to clone-and-modify the whole LLVM tree? (And what if I want to
compile Rust to Javascript? Which of these incompatible LLVM branches should I
use?)

~~~
sanxiyn
Rust does work with LLVM releases. In the past it didn't because of various
bugs in LLVM, but all blocking bug fixes landed, where "blocking" is defined
as those preventing compiler bootstrap. Currently, Rust CI checks for every
commit that it bootstraps with LLVM 3.7 branch.

Rust maintains the fork because in the foreseeable future, there will be non-
blocking bug fixes and Rust will not follow LLVM trunk to get them.

------
vvpan
The title is a bit misleading. It is deprecated in the context of that
project. Meaning they personally won't support it anymore. It's not deprecated
in general as a compiler.

~~~
smegel
Did the title not have "Android NDK:" in it at some point?

~~~
whatever_dude
Pedantic much, but I agree. GCC _support_ is deprecated, not GCC itself.

------
jdlyga
Perhaps for Android, but I'm hesitant about using Clang for Win64 due to some
recent bugs (such as tellg not working correctly).

~~~
klodolph
That's probably a bug in libc++, not Clang. They're under the same roof, but
different people work on them.

Also, I would mock you for using <iostream> at all but you've probably got
legacy code just the same as I do.

~~~
Buge
I'm curious, what's wrong with iostream?

~~~
cbd1984
How do you internationalize strings built up from multiple string fragments?

~~~
simoncion
The same way you'd do it in printf? Stringize data and insert it in the middle
of static text? (Pardon my inelegant code, I've been away from C++ and doing
Erlang for quite a while now.)

    
    
      void printStuff(ostream Os, 
       string WarningPart, string SizePart, string EndPart, int Size) {
        //The English version might look like:
        //"Warning: Size too big (200). Get smaller."
        Os << WarningPart << SizePart << Size << EndPart << endl;
      };
    

I expect that if I thought about the problem for a few minutes (and was unable
to find any C++ i18n libraries) I would come up with something _much_ nicer
and easier to use than this thing I spent ten seconds working on. :)

~~~
prodigal_erik
POSIX printf allows a translator to write a conversion spec like "%1$d" that
says _which_ arg to print. This lets you do stuff like put currency before or
after the amount depending on what's idiomatic for the locale, without
recompiling (if you lookup your format strings at runtime).

~~~
simoncion
Sure, but that's l10n, which is a different -but related- thing. :)

printf format strings are well thought-out. I was demonstrating that the same
ideas can easily be used with io*stream.

~~~
simoncion
For the downvoters: Here's a lib that accomplishes this task that's had a fair
bit more than 10 seconds of thought put into it: [0]. Examples [1][2].

:)

[0]
[http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/in...](http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/index.html)

[1]
[http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/he...](http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/hello_8cpp-
example.html)

[2]
[http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/me...](http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/messages_formatting.html)

------
fithisux
While for NDK it is deprecated for general use GCC has a bright future.

At least on windows, it is FOSS with a complete SDK for Win64.

Clang requires the Windows/Platform SDK. You cannot really use it without it.
You cannot create a distribution without it.

------
qeabc
Some comments about how GCC could have avoided this made me think that this is
a setback for free software, but why isn't this just a rising tide benefiting
both free and proprietary software?

The NCSA license explicitly allows sublicensing, so both the GNU project and
Microsoft can create derivatives under free and proprietary licenses
respectively, for example.

[I am not a lawyer, but this is the reasoning of the accepted answer to a
stackexchange question applied to the NCSA license:
[http://programmers.stackexchange.com/questions/105912/can-
yo...](http://programmers.stackexchange.com/questions/105912/can-you-change-
code-distributed-under-the-mit-license-and-re-distribute-it-unde)]

------
sunnyps
> Ctrl-C no longer kills the backgrounded gdbserver.

Woohoo!

------
bracewel
_waits for RMS to get mad_

[https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html](https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html)

~~~
Aloha
RMS is nothing if not ideologically consistent. I applaud his goals and
perseverance, even if they are not quite the same as mine.

~~~
BrainInAJar
He's consistent to a point. He's quite silent about the hardware aspect, even
though free software licensed CPU designs have been available for a long
while.

~~~
jimktrains2
Designs have been, but have actual chips been?

~~~
sliverstorm
If you have the design, and you have access to FPGAs, I'd say that's got you
pretty close already.

Edit: We were talking about CPUs, not complete systems. And yes, the
performance would be poor, but RMS has already strongly established that in
his book performance is a distant runner-up to free.

~~~
BrainInAJar
>By pretty close you mean no where near a usable system then you'd be correct.
If you're not a hardware person, as I'm not, I don't think I could go from
blank fpga and parts to a working laptop with a keyboard, trackpoint, and lcd
screen in any reasonable amount of time, nor with any certainty that it would
work and not be error-prone.

The exact same argument can be made about the operating system.

~~~
lmm
I can and have patched bugs in my operating system.

I have no clue where I'd even start to patch a bug in my hardware.

~~~
jacquesm
If you're lucky it's off-chip and your soldering iron and a very sharp knife
will come in handy.

The problem with 'patching' hardware these days (oh, I'm that old) is that
most of the time you'll find your problem is located inside a chip, and it
isn't the traces are in planes that you can't access (if you're lucky they
might run in a spot where you can dremel through and then cut and solder two
small wires to the buried trace). Via's don't help either (especially not in
layers that start and end under BGAs).

Patching hardware was never easy, but with todays degree of integration of
components and SOCs it is harder than ever and frequently downright
impossible.

Lots of things have gotten easier since the hole-through era, but hardware
fixes aren't one of those.

~~~
lmm
I guess the counterpoint is that there are things you can now fix in microcode
that would have previously required messing with the hardware?

~~~
jacquesm
That depends. Microcode tends to be used in CPUs rather than regular ASICs and
not all CPUs have re-writable microcode (though quite a few of them do). So
unless you're talking about a CPU the answer is probably 'no'.

You probably have a bigger chance that there is an FPGA on board that you can
re-load.

------
tobias3
When we tried using clang for Android compiling C++ code half a year ago it
caused problems, which disappeared when we switched to GCC.

> If you have problems with Clang, please file bugs!

Filing compiler bugs is really hard with a closed source project.

~~~
salgernon
Compiler bugs are usually limited to a single compilation unit and are usually
submitted by doing a binary search on a pre processed source file. This is
certainly true for closed source as well - just redact the (few) symbol names
and create something that will compile to an a.out that demonstrates the
problem.

God saves a puppy anytime someone filed a compiler bug with a trivial test
case that demonstrates the problem.

~~~
onedognight
> God saves a puppy anytime someone filed a compiler bug with a trivial test
> case that demonstrates the problem.

The current (r10e) shipping version of clang cannot return 128bit floats from
a function.

    
    
       #include <iostream>
       int main(int c, char **v) {
           std::stringstream("1.5");
           double x; s >> x;
           return x == 1.5 ? 0 : 1;
       }
    

EDIT: You don't need "long double" in the above. double (or float) will show
the problem. The standard library converts all floating point numbers to long
double internally.

~~~
kevinchen
Ran the program with some slight modifications and couldn't reproduce it

    
    
       #include <iostream>
       #include <sstream>
       int main(int c, char **v) {
           std::stringstream s("1.5");
           double x; s >> x;
           return x == 1.5 ? 0 : 1;
       }
    
    

Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin15.2.0
Thread model: posix

~~~
jevinskie
I'd be wary of concluding that "if it works on Apple Clang, it will work on
all Clangs". I've seen this to be untrue in multiple cases and the root cause
can be found in a multitude of locations. LLVM, Clang, libc (glibc, musl,
MSVC, Apple libC,), C++ STL (libstdc++, libc++, MSVC), compiler-rt, platform
ABI (Apple ABI's are pretty much SysV, except when they aren't...), and of
course the actual version/branch of all of these things. It is certainly a
start but unfortunately an over-generalization. :)

~~~
Narishma
Just tried it with clang 3.6 on Linux and couldn't reproduce it either.

