FreeBSD Throws the Clang/LLVM Switch: Future Releases Use LLVM 360
An anonymous reader writes "Brooks Davis has announced that the FreeBSD Project has now officially switched to Clang/LLVM as C/C++ compiler. This follows several years of preparation, feeding back improvements to the Clang and LLVM source code bases, and nightly builds of FreeBSD using LLVM over two years. Future snapshots and all major FreeBSD releases will ship compiled with LLVM by default!"
Re:What's the clear advantage of LLVM? (Score:5, Interesting)
I know of LLVM, but haven't used it, and it really seems like very few hardcore Linux/OSS devs have a clue about it. Is there really a clear advantage, or is it just an excuse to write a new compiler to solve a problem that doesn't exist?
Much better modularization, so that the tokenizer used by the compiler is easily available to other tools, so that your editor does not have to (try to) re-implement all the intricacies of C++ syntax, so that parse tree & symbolic info is available to your IDE, so that it does not have to try to re-implement parsing of all the intricacies of C++ templates & namespaces in order to give you cross-referencing or even re-factoring functions (not to mention support for a debugger that can actually figure out types in a complex inheritance hierarchy).
Re:What's the clear advantage of LLVM? (Score:1, Interesting)
That would be bad for us. Clang is in the order of 10 times faster than GCC (compilation speed) and the generated binary is 1% faster than GCC (so essentially the same but saves hours of compile-time per day on 50MB+ C-files).
Don't knock it until you've tried it (Score:4, Interesting)
FreeBSD might not be anywhere near as popular as linux but its a damn good system, and whats more there arn't endless ever-so-slightly incompatable distributions of it. Ok, its never going to threaten Linux but its good to have a proper alternative free Unix system available that is actually interested in its end users and isn't just a pet project of the devs (unlike certain other BSDs I could mention).
"economic reasons" (Score:5, Interesting)
A lot of graphics software infringes on existing patents, but that isn't a reason you can state without risking treble damages in a lawsuit, so most of the graphics driver writers tend to just look the other way and hum as they dance past that particular graveyard. Practically, it's impossible to write genuinely competitive graphics code without infringing some East Texas idiot's patent.
There are also cases where code has specific strategic value to a company, and they want to amortize the cost of development over some period of time before they let their competitors use the code. For example, the Soft Updates code that Kirk McKusick, Julian Elisher, and I worked on for FreeBSD was licensed under a free-for-non-commercial-use license for a period of two years before we opened it up for general use. This was to allow us to recoup the investment on developing the code by allowing us to run our hardware without a UPS, while everyone else in the market had to have a UPS to deal with power failure and recovery. If you don't have it, you have to treat a power failure as a kernel panic and do a full fsck in order to return your disk to a known good state, since you can't otherwise guarantee that it wasn't a crash followed by a triple fault, which might have written bad data to some portion of the disk. So all the competing border router/SOHO server devices had to have batteries, which increased their cost relative to our product. It's one of the reasons IBM bought our company.
Yeah, it'd be great if some idiot were to spend 10 years of their free time neglecting their families so that all this stuff could be free, but no one really wants to be that idiot: people work on free software for love, and they work on the hard problems and productization in exchange for money, since no one is going to do scut work for free unless they're a masochist (if you happen to know one, though, I have a project or two they could tackle if they really wanted to suffer).
Re:Grin (Score:5, Interesting)
It isn't necessarily an issue with the GPL (aside from 3 being invasive, which I personally have an issue with and so do the lawyers I work with) - I have a problem with Stallman's (aka RMS) model, which says charge for hardware and give the software with source away for free.
I worked for a CAD software company (we were bought by a huge multinational conglomerate, so I technically still work for them, but I moved around and rarely touch CAD these days). In our former incarnation, we sold exactly no hardware and were bundled with exactly zero hardware, but ran on pretty much every platform imaginable (9 at one point, but much fewer now, since our customers are mostly moving to Linux or Windows). Giving away our software (not to mention the source code) would be a really bad business model, but to appease those in RMS's dream world, we'd need to find hardware partners and give it away for free with the hardware and be paid by the hardware vendor - but since we have to give away source, we'd more than likely use an in-house developed proprietary language to make porting as difficult as possible. This, in fact, is a BAD and not very open business model - if we'd been bought by our current owner, we'd almost certainly be proprietary software for their hardware and not run on platforms like Linux or even Windows. This happens in the console world all the time - when Microsoft bought Bungie, they basically shafted what Bungie was known for - mac games (and took a year to release Halo on Windows/Mac to keep it XBox exclusive as long as possible to the ire of Steve Jobs - later releases became XBox exclusive). If you think that is a good thing, great for you - I don't. Incidentally, the part of the company I work for has an open data model as well - that makes it easy for customers to switch, but we are doing our jobs well because few actually do.
I've been at odds with RMS over this for years...
Re:Grin (Score:4, Interesting)
unlike GCC, Clang/LLVM was designed to ensure the optimizations are the same each and every build. This means you can compile from source and check the md5 sum of your binary against the master md5 and know if the source has been modified before compilation. Critical for signed binaries.
Another benefit is the support for older hardware that's been dropped by the GCC team along with ease of debugging. I've had compiler optimizations introduce unexpected bugs/failure mode in the Linux kernel itself that disappeared when the No Optimization flag was set. Simply put, if the kernel isn't stable, I don't give a damn how stable the rest of your system is, it's not stable because you can't trust the kernel and that's why Clang/LLVM is all about.