5 ms·
No, we won't. The respective communities have been developing with GCC in mind for years. While clang is fantastic, I doubt that an outright replacement will ta
by apl 16y ago
No, we won't. The respective communities have been developing with GCC in mind for years. While clang is fantastic, I doubt that an outright replacement will take place.
But emancipated co-existence would be neat.
- JoachimSchipper 16y agoActually, quite a few BSD people will be happy to have a non-GPL compiler. AFAIK, your comment is spot on for Linux, though.
- _delirium 16y agoFor those BSDs that target a wide range of architectures (NetBSD is the canonical example), it'll be a while before they transition completely, since the gcc ports list is still considerably larger than the LLVM one.
- JoachimSchipper 16y agoSure, OpenBSD won't be transitioning anytime soon either - indeed, there are a lot of architectures that aren't supported by LLVM yet, and making sure everything worked with gcc-4.x was enough work...
- apl 16y agoYes, you're absolutely right. It's a blessing for the BSD community. However, when someone mentions "most/all" free operating systems, then Linux and related ecosystems are one hell of a big elephant in the room.
- dazzawazza 16y agoThe main reason for moving to clang is to remove as much GPL code from *BSD as possible (kernel and system libs). You are correct regarding many of the 'ports' (packaging system) though as there will no doubt be some GCC idiosyncratic code in many of them.
- X-Istence 16y agoOn the ports build clusters they are doing experimental runs using -CURRENT with clang/LLVM as the only compiler for the ports tree in an attempt to weed out what would be broken and what will work without changes. So this is definitely something they are already testing.
- avar 16y agoUbuntu is already considering switching. Most people don't develop with "GCC in mind". They just target it, but now that there's another compiler that compiles almost all GCC C out there the cost of switching is very low.
- StavrosK 16y agoI'm not too familiar with C, but don't compilers have to adhere to the standard? Is the issue developers who depended on GCC-specific behaviour for things the standard doesn't document?
- obneq 16y agosome things are left undefined by the standard, here compiler implementors can do what they will. Another thing are GNU specific extensions, not only in GCC, leading to GNUisms in many scripts and sources. LLVM supports many GNU extensions.
- riffraff 16y agogcc, like other compilers, has it's own documented extensions which are used in many projects (such as the linux kernel, but also many interpreters/vms using direct threading for example). The clang devs try to support them nonetheless for compatibility, except, for what I understand, a few that are explicitly unsupported by design.
- avar 16y agoCompilers are free to implement extensions if they want. A lot of programs depend on GCC extensions, so you'd never be able to compile e.g. a modern Linux distro with just an ANSI C compiler.
- sp332 16y agoThe standard just means that if you write "standard C", the compiler will work as expected (for some reasonable value of expected). But compilers can add extensions, and GCC has a long list of extensions. The Linux kernel uses these GCC-specific features a lot! Here's a list of extensions, if you're curious... http://linuxdevcenter.com/pub/a/linux/excerpts/9780596009588/gcc-extensions-to-the-c-language.html http://linuxdevcenter.com/pub/a/linux/excerpts/9780596009588...
- X-Istence 16y agoFrom what I have gathered in the past, and what has been said here on Hacker News as well, FreeBSD is looking to replace GCC in the base with clang/LLVM, and that is exactly where this move is going. As the mailing list message specified clang is going to be the default on i386 and x86_64. GCCisms will eventually go away and the code base will be cleaner and more manageable based upon it. As states in the FreeBSD status report for this last quarter there are already experimental tests being run on the FreeBSD ports build system whereby clang/LLVM are used to compile all of the ports in an attempt to see how far clang/LLVM can get.