Live data from Hacker News

Android NDK: GCC is now deprecated, everyone should be switching to Clang

android.googlesource.com

221–230 of 259 posts

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#221
post #3

waits for RMS to get mad https://gcc.gnu.org/ml/gcc/2014-01/msg00247.html

This comment breaks the HN guideline that says Please avoid introducing classic flamewar topics unless you have something genuinely new to say about them. It has triggered a devolutionary cascade that so far has made it as low as "Wow, what an asshole" and "man who thinks sex with children should be legalized". Blasting craters in the threads like that damages this site. I'm sure you didn't mean to, but please don't do it again.

https://news.ycombinator.com/newsguidelines.html

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#222

Earlier quoted context omitted.

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 addit…

So FSF is basically PETA of software world.

Not really.

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#223
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?)

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#224
post #108

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…

Here's one incredibly awesome feature of Clang: Windows support (thanks to Google, actually). No Cygwin/msys required -- it implements the Windows calling conventions, exception handling, etc. You can link modules compiled with Clang using the Microsoft linker. https://www.youtube.com/watch?v=dr0eY9c23i8

mingw (now mingw64) has been doing that for ages as well -- I'm too busy to check right now, but I suspect since before clang supported windows.

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.

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#225
post #135

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.

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

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

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#226

Earlier quoted context omitted.

The dream of a GPL world only ever worked if the entire ecosystem was GPL and it was possible to derive a living from ecosystem. The revolution never happened. One could even argue that RMS' more civilized age never really existed outside of the MIT AI lab so it was doomed from the beginning. Due to his stubbornness in not accepting the realpolitik the savannah has now become a reservation that is shrinking daily as…

In GPL world any user is a developer too. This might have been true at the begining, but it is very far from true now. That's what RMS failed and still fails to grasp.

I think you've got it backwards; In GPL, every developer is a user. This becomes apparent when you see why the GPL came into existence and what it sets out to accomplish (Safe guarding users' freedoms at the expense of the developers').

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#227
post #223

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?…

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.

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#228
post #91

Earlier quoted context omitted.

> C already has rock-solid string formatting options Don't troll.

Do you have an actual response? How is iostream any better than *printf? At least you can read the format of the former without needing to google un-googleable operators.

> How is iostream any better than *printf? printing user-defined types?

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#229

Earlier quoted context omitted.

Better security features for one. Clang supports SafeStack and Control Flow Integrity. SafeStack is much more performant than gcc's stack protectors, and gcc offers no equivalent of CFI.

So, I'm not familiar with all of the CFI protections available in clang, but is full CFI actually implemented in CLANG? 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, sta…

Clang's CFI implementation is documented here: http://clang.llvm.org/docs/ControlFlowIntegrity.html

It's not a full CFI, but my understanding is that it does completely prevent vtable corruption with ~5% overhead (measured for Chromium).

Re: Android NDK: GCC is now deprecated, everyone should be switching to Clang

#230
post #101

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…

Clang had a number of benefits over GCC such as better error messages and integration points for IDEs (syntax checking/etc) which caused Apple to switch to it (on top of licensing). It may have been faster, not sure, but the internals were supposed to be MUCH cleaner and easier to work with. I know a number of these issues have been improved/fixed in GCC over the last few years. Outside friendliness to internal tinke…

> not sure, but the internals were supposed to be MUCH cleaner and easier to work with.

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

Post reply on HN