Android NDK: GCC is now deprecated, everyone should be switching to Clang
android.googlesource.com
android.googlesource.com
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.
Fortunately, given that Graydon did prefer a permissive license for the compiler, LLVM provided exactly what he was looking for.
Might be hard at first and not very compatible with different compilers, but it is doable
...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.
(I'm going to get that on a t-shirt, printed in block letters: "Stallman is correct.")
He was tactically wrong in taking an expansive view of both what free software licenses should enforce and what fell within their realm of enforcement. He was hoping that GCC would be so much better than the competition that people would use it despite it being GPL, and for a long while (e.g., NeXT's Objective-C patches) it was. But the GPL, especially the GPLv3, was perceived as way more onerous than Stallman expected it would be, and eventually it became worth people investing heavily in a competitor just to avoid the GPL. If he had aimed a little less high with the GPL and admitted a plugin architecture / documented IR for GCC earlier, then LLVM may never have taken off.
Alternatively, he was tactically wrong in thinking that strong copyleft was required to achieve the goal of software freedom. Note that the clang in the NDK "is now a nearly pure upstream clang," not because they're required to, but because the pace of modern software development makes it genuinely easier to voluntarily submit changes upstream.
You can't do anything about haters.
Steve Jobs' perception, and NeXT/Apple's perception, never changed. What changed is that in the NeXT days, GCC was so much better that Apple said, we'll make the tradeoff of using GCC even though we don't want the GPL. A few years ago Apple said, we'll make the tradeoff of avoiding the GPL even though we want GCC. And they went and invested significant resources into LLVM.
The GPL was meant to be a tool to get people who did not perceive free software as in their best interest to contribute to free software anyway. It might not have changed whether they were "haters" as a matter of opinion, but it was definitely intended to change their concrete actions. And it did -- for a very long time.
It's much easier to compare them philosophically.
Commercial/ Proprietary - unrestricted free market capitalism
Copyleft licenses - socialist (not communist, there's a difference people, learn it) / commercial cooperative (think farmers cooperatives and anyone who might use a .coop domain)
Permissive licenses - various anarchistic philosophical positions
Market anarchism is much more compatible with existing corporate dynamics so it's pretty easy to see why it's trending this way.
Due to his stubbornness in not accepting the realpolitik the savannah has now become a reservation that is shrinking daily as people abandon it for more liberal climes.
The upshot is that the GPL just creates additional friction for developers in the pursuit of ideals that, statistically speaking, nobody really cares about. This is why it is misguided.
The primary purpose of the GPL is to insure that users have the freedom to modify and redistribute the software they use should they choose to do so. Whether the user does so or not is irreverent. That's why I don't think it's a matter of whether end users care, or how large of a percentage they form of the overall user base.
Developers who decide to license their work under the GPL do so to safeguard their own freedom and the freedom of their users. To that end, I think the GPL hits its mark.
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.
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.
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.
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.
I feel like you are missing the point of the GNU GPL.
(I was going to go for the car example, but that is less and less true. We do not own our car anymore.)
So let's put it this way: The FSF didn't pivot when they had a chance to capture a larger market!
I'll bask in the downvotes that comes with telling the harsh truth. I got karma to burn, folks.
So although it hasn't succeeded for phones yet, building on top of tech stacks contributed by others (who haven't fully bought in to the same goals, but are sympathetic in some ways) still seems like a great strategy. The free software community needs to finish the job.
On the other hand, going fully independent and building stuff separately without those contributions (which seems to be what some free software folks want to do with commercial-unfriendly licenses) doesn't make a whole lot of sense to me. If you can't succeed even with substantial help, how do you succeed without help?
pity about the drivers though. at a speech in copenhagen stallman was encouraging people to start reverse engineer these.
it's nice that at least some of the phones are somehow open.
It's true that the Free Software federated systems that are more strongly based in ideology that bringing use-value to users have generally failed to experience uptake, but that should probably not be considered a surprise.
https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00...
By creating a hard line, and building a compelling alternative to proprietary compilers, he introduced a seed of change in the minds of young programmers at that time .... All of whom are senior management now and share a belief that things like Protocol Buffers should be open source.
In fact, its interesting that Android is inducing this change all over again (not Linux). Its a viable answer to "its not as good as an iPhone,why should I buy it".
Now everybody cannot think of sofware as naturally different than propietary.
Hence giving an opportunity for a natural monopoly. Bill gates used security an argument a lot, and only became a little more secure by using permissive open source or buying software from poorer concurrent that had no good backup from their banks.
Bill gates is the baron de Beaumarchais of computers : whining about being riped of software he did not created because people would give the interpreter so that their code could be used.
A right on the second creation.
Just for the record Beaumarchais, whining for special treatment as an artist. He was a smuggler, a weapon dealer, a baron, an aristocrat, and a revolutionary AND he created the fundamental rights of authors.
The true fundation of liberalism: as long as it works for me, let's do revolution.
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... This is almost a year old, though
I know a number of these issues have been improved/fixed in GCC over the last few years. Outside friendliness to internal tinkering and non-GPL software I'm not sure if one as serious technical superiority. I believe clang is written in C++ instead of C, for whatever that's worth.
GCC has always had a much bigger set of supported platforms and processors.
I've bookmarked this bit of GCC code for my own amusement - an anecdote about the quality of GCC's codebase:
https://github.com/gcc-mirror/gcc/blob/7057506456ba18f080679...
Also, I believe ASAN started with clang.
- 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.
egcs, on the other hand, was a much needed kick in performance and features of gcc, but had the negative of making it harder to maintain and understand.
lcc was a good example of moving back into the simple compiler design, but it seemed to have stayed more in academia.
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
No Cygwin/msys required -- it implements the Windows calling conventions, exception handling, etc. You can link modules compiled with Clang using the Microsoft linker.
gcc has had support for every operating system under the sun at one point or another - I fondly remember using the DJDelorie version for DOS+Extender, and if I'm not mistaken, there was also a release that could do WIN32 on Windows 95 from delorie.
Especially with C/C++, there are a lot of potential attack vectors that would need to be closed (stack smashing, ROP, Vtable corruption). From a laymans perspective, some of these need full memory corruption protection.
Any references would be appreciated. The last time I had to adress CFI in C, static analysis (with greater precision than CLANG had) was involved.
It's not a full CFI, but my understanding is that it does completely prevent vtable corruption with ~5% overhead (measured for Chromium).
So while they may still be lagging in some areas, I'm confident they'll get ahead of GCC in those areas long before GCC catches up in the areas where it's behind.
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
The SoC manufacturers mess around with proprietary peripherals and obstructive boot processes, but haven't messed with the actual instruction set.
LLVM is designed to be modularized and embedded in other binaries and toolchains, which makes it easier to build extensions and tooling around it.
In addition to having a mountain of legacy code, gcc's project steering is philosophically opposed to allowing non-free (as in GPL) plugins [https://lwn.net/Articles/582242/]. Because of this, developers looking for the most flexible toolchain seem to be backing slowly toward the exist regarding gcc, as the Clang / LLVM steering team has made clear that they don't see similar incompatibilities between their tool and the way developers choose to use it.
There is a project going on to break the gcc down into components [https://gcc.gnu.org/wiki/rearch], so time will tell what comes of these two toolchains.
I think that's the right philosophy. Why shouldn't you be contributing your plugin if you derive value from it, so that other people can derive value from it just as you did with GCC (if you distribute it that is - if you wrote it inhouse for internal use, then it doesn't matter at all!).
It's not like the code generated by GCC is licensed virally.
It's a shame that GCC's code is hard to modify, and difficult to extend. LLVM's permissive license means that contributions don't flow back unless it's favourable to the entity contributing it (such as good PR). I imagine that if somebody/some company wrote an excellent, non-obvious, non-trivial toolchain using LLVM, derive profit from it, they will not _want_ to contribute it back.
So, the FSF sacrificed technical needs in order to serve philosophical goals.
There are multiple reasons to push code up the chain to the wider world beyond fuzzy feelings regarding your corporation.
Never underestimate the benefits of outsourcing your code maintenance and integration costs. ;)
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.
Last time I checked gcc binaries beat Clang performance wise.
Several extension mechanisms have been built out in the last few years, including plugins for intermediate passes of compilation, and a library to operate as a JIT.
Eddyit: Spelshing.
B) If you ever want to make a change to the toolchain, HARD SWERVE on supporting GCC. It's a liability if you need to modify it at all. This may have more to do with what Google wants to support rather than any effect on the end user.
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?)
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.
From the link: "Also note that Clang packaged in the Windows 64 NDK is actually 32-bit."
Also, I would mock you for using <iostream> at all but you've probably got legacy code just the same as I do.
Don't troll.
Type checking.
You should: https://news.ycombinator.com/item?id=10775022
It doesn't work with non-constexpr format strings, but there aren't many justifications for those.
What consistent mechanism do you use to printf an instance of an arbitrary user-defined type?
With ostream, you implement
ostream& operator<<(ostream&, const Class&)
with printf, you have to have a convention and remember to stick to it. (Do I call .toString(), .stringize(), .getString()... ??)
For one-off things, printf is great. You take it from me when you pry it from my goddamn cold, dead, hands. However, for real work io*stream are rather nice.
[0] I mean, it's obvious that anything that you don't get for free out of the box is bound to _not_ be universal. Edit: Actually, the thing you get out of the box when you present an instance of a non-trivial user-defined class to both printf and ostream is equally useless... unless you're debugging and are interested in the address of the instance of an object.
It buys you the same thing that API consistency always buys you: reduced cognitive overhead when dealing with a given API. :)
Edit: As GFK_of_xmaspast mentions [0] instances of non-trivial classes are not compatible with the default implementations of "operator <<" in ostream. So, you can try "ostream << instanceOfNonTrivial". If it passes the compiler, then you know that operator << is defined for that class.
So, no need to check the docs... just ask the compiler. :)
Or give it a go and see if the ide/compiler complains.
Thanks for reminding me of this. Kudos!
That's not what's going on. Neither C nor C++ really permits that.
We're just talking about the relative merits of using printf and friends vs. using iostream to format data for the console or disk.
In either case, you have to write the code for your class that massages the class's internals correctly, but the question is, do you write to the ostream extraction and istream insertion API, or do you write to the substantially less well defined printf-and-friends API?
If you have a fundamental misunderstanding of the meaning of an operator, it's pretty easy to fail to correctly read a section of code.
Maybe you're someone who hates operator overloading. If so, that's a pity. It's a useful power tool. [0]
[0] Yes, all power tools can be abused. That conversation is tired and not worth revisiting.
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;
};
printf format strings are well thought-out. I was demonstrating that the same ideas can easily be used with io*stream.
:)
[0] http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/in...
[1] http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/he...
[2] http://www.boost.org/doc/libs/1_60_0/libs/locale/doc/html/me...
With printf, we have gettext. I don't really see how there's any analogy for gettext in iosream-world.
Funny thing. Boost more-or-less uses gettext, too! https://news.ycombinator.com/item?id=10774941
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.
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...]
Woohoo!
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.
A bit more tricky with or1200, but this way you'll get a fully functional Linux workstation.
The exact same argument can be made about the operating system.
I have no clue where I'd even start to patch a bug in my hardware.
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.
You probably have a bigger chance that there is an FPGA on board that you can re-load.
To him, maybe. Not all of us have the luxury of getting paid to be a techno-luddite, using antiquated workflows and having the spare time available to re/write drivers when necessary.
If I made the same performance/freedom trade-offs I'd be completely unable to do my job.
The people who want non-copyleft licenses to succeed are those who which to make a profit from the control and ignorance they can impose on their users by closing their source and platform or those who are willing to trade their user's freedoms to appease them.
Businesses have a huge amount of leverage on the OSS software ecosystem and so it's really no surprise that the licensing choices are to benefit the businesses funding the development rather than the users. It's to be expected but no less sad. There's a small group of passionate people who have basically dedicated their lives to making the world a better place by writing software that's truly free and respects its users, they built an entire community and movement around the idea, and actually stand by their beliefs -- yet people dismiss them because the company worth hundreds of billions of dollars has a better UX.
True, mostly thanks to shitty companies like Apple, Microsoft, Autodesk, etc.
>You as a developer and a user should want the freedoms afforded to you by the GPL or any copyleft license for that matter.
I do.
>In the ideal world your high performance software would be released under the GPL you would have the best of both worlds.
We don't live in an ideal world and never will.
>The war won't be won by rewriting every single tool and releasing it under the GPL, it will be won by pressuring existing companies to license their software under the GPL.
This doesn't work, especially in software for engineering where there are often sole, hegemonic powers and established monopolies and where the cost to enter the market as a new competitor is non-trivial. We're not talking a desktop manager or a text editor here, we're talking millions of dollars of R&D for things like CFD suites. Open alternatives exist (like, say, OpenFOAM) but they often lack accreditation/certification/rigorous testing and when you're dealing with people's lives the choice is often proscribed entirely.
>The people who want non-copyleft licenses to succeed are those who which to make a profit from the control and ignorance they can impose on their users by closing their source and platform or those who are willing to trade their user's freedoms to appease them.
There's a financial incentive to creating walled gardens and proprietary software that you can charge for.
>yet people dismiss them because the company worth hundreds of billions of dollars has a better UX.
When the choice is between "being able to function at my job, at all" and "use free software", well, the choice is clear.
Probably because it's not software.
I am annoyed by the FSF dogma because they lay an exclusive claim on the word ethics when applied to software. I consider myself an ethical person even in software. But my definition of ethical is less strict than the RMS definition.
I'm not sure that's a fair characterization. They've defined an ethical framework for software and then they discuss things being ethical or not within that framework.
Anyone is free to use a different ethical framework and decide if an action is ethical or not within that framework instead.
We're already very close to that world. Many people seem happy to see GNU losing ground every day. For myself, I am not sure that we are working towards the best possible future, but I'm not even sure what that future should be.
Maybe GNU is just a stop-gap movement to get everyone on board the FOSS train, who knows. BSD licensing hasn't caused any apocalypse yet and arguably it provided a networking stack for Windows that was superior to anything MS could rush out the door back in the NT 3.5 days. There's something nice about being able to put the code into commercial products without worrying about strict GNU/GPL-like conditions.
If most people defaulted to sharing code like was done pre-Microsoft then BSD would be fine. Read RMS's rant that is linked above. He's still at defending against "adversaries" of Freedom. This is war!
OK, so even MS is now open sourcing (some of) their code. Maybe it's not "war" anymore, but you need to understand the history a little.
Didn't Gates' letter come out ten or more years before the first version of the GPL.
This is why rms is the way he is. He's old. He remembers the days when all software was free. He's been trying to get that back ever since.
It is hard to see the entire impact of Free software and even harder to predict how the world would like if people actually stood up to it but I can say that I am sure we would have:
- more secure Internet - more decentralized/distributed Internet - no ISP blocks - much harder if not even impossible NSA spying - no disgusting DRM - no patents and patent trolls -> more inovation - no force updates, no abandoned users - more competition in hardware and software field - things being developed for people and not sheer profit - ... - add your points
A lot of hard problems come from the fact that you need lots of developer attention to build and maintain solutions that just work. The domain is tricky and complex enough to where, you can make it zero-effort for one configuration, but making it zero-effort for all possible or even all likely configurations takes more resources than is available.
The example relevant here is cryptography software. It's not hard to encrypt stuff. It's hard to make end-to-end solutions that just work, for all possible uses and across all possible platforms.
Free software has a restrictive effect of only making software platforms that are open and extensible, vastly reducing the effort needed to maintain end-to-end, user-friendly encryption.
It would make it pretty much impossible for the NSA to spy on citizens if we only had free software platforms to support.
> If you have problems with Clang, please file bugs!
Filing compiler bugs is really hard with a closed source project.
In any event, you can file bugs here: https://code.google.com/p/android/issues/list?q=label:Compon...
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;
}
I see mention of long double in your edit, but even then wasn't that 80bit on PC architecture. Only Solaris and HP-UX? defined that as 128bit.
#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;
}
I wonder if the bug you are seeing is a result of the C++ STL and not the compiler itself. Can you try reproing with libc++?
""" We’ve moved our bug tracker to GitHub: https://github.com/android-ndk/ndk/issues """