The project compiles now, but the resulting executable is still not passing basic regression tests :)
I think our codebase has been depending for too long on just one compiler, and clang C++ support isn't perfect yet. (FreeBSD has mostly C code which is very stable). I will keep pushing to get it all working :)
Or maybe it's C++ violations that are "commonplace" and would break several existing softwares.
And herein lies the biggest hurdles with C++
Heavy templating and inheritance is the way to ensure your C++ program will be unmaintainable and not forward compatible with GCC (or other compilers)
I've been in a similar situation where I spent a lot of time fixing compiler errors (on GCC 3.X if I'm not mistaken) that would be ignored on 2.X
The code builds with Clang, but the runtime crashes deep inside Boost.
It's been very frustrating because we're well past the point where refactoring-out Boost would be cost effective.
I'm curious: What was the motivation for switching in the first place? And why is staying with the proven tool not the better option?
My own case: It makes no sense to migrate our (relatively small by the sound of it) codebase. It is in production, generating money, and anything that interferes with that is simply not going to be considered. Our largest dependencies are wxWidgets, ffmpeg, libcurl: It has performed well, though not without some hiccups.
Apple won't allow us to submit apps built with Xcode 4.1 forever. (4.1 was the last to include GCC.)
Thanks for the reply.
Linus' ultimate plan for Linux. Replace brain with Linux. Circle complete. Spleen still uses binary blob for driver. Open-source attempt to recreate it called Splouveau.
clang, now with a compile-to-DNA backend.
That implications are disturbing.
Someone want to give (or link to) a brief rundown of the advantages/disadvantages?
Outside the license, the main benefit seems to be that in Clang the different stages are less intertwined than GCC. This is supposed to make developing Clang easier (since you don't have to understand so much), allowing optimizations to be tested and added easier.
On the user side, Clang is well known for providing much better error messages. Some error messages will even suggest possible fixes (you might get something like "Can't assign a pointer to a something, did you mean *pointer?").
The GCC guys have been improving their compiler for a long time, and over the last few years they have been working hard to make GCC easier to work on and optimize. I believe that GCC is usually faster or the binaries are smaller by a few percent, but it's not generally a drastic difference.
It's important to note though that it has only been recently (starting with GCC 4.4) that I've started to see some _improvement_ over previous GCC versions. GCC 3.x was known to be bloated, buggy and emit poor code for almost every architecture. Open64 was superior in _all_ regargs up to GCC 4.2/4.3 in my opinion.
Clearly, the whole project greatly benefited from Clang's competition.
 : http://gcc.gnu.org/wiki/ClangDiagnosticsComparison
Here  is an example of Xcode leveraging clang to provide valuable feedback. The second picture speaks volumes.
I'm not sure how it works in Clang, but of course, GCC doesn't "see" macros, this is seen by the CPP (C pre processor) and GCC operates in C code only
There's a flag (-E) that makes GCC output the preprocessed code and stop
Faster compile times.
Better error messages.
BSD license.(More in line with their project not a judgement on my part.)
Designed to make use in tools easier.
Code produced isn't as fast, but not much slower.
HOWEVER the GCC he tested against was GCC 4.2, a ~5 year old version of GCC which is the version OSX ships with (he was using OSX) so the tests as comparative between GCC and Clang/LLVM of today were pointless.
It should also be noted that Firefox as used on people's machines today gets a large performance boost from profile-guided-optimization (remember back when people noticed that win32 Firefox under wine was faster than native Firefox on Linux? This was because of the Linux versions not being compiled with profile-guided-optimization at the time), and this optimization is not available for Clang/LLVM (though iirc there's a GSOC project for it this summer).
The claims about who has faster binaries are pretty difficult to judge - it seems they really are about equal. It may be highly superscalar CPUs with instruction reordering and register aliasing hide the difference.
 http://gcc.gnu.org/ml/gcc/2012-02/msg00134.html (probably unbiased) and http://clang.llvm.org/performance.html (probably biased)
Many of the Clang vs. GCC tests are clandestinely skewed towards llvm because they involve code that does not benefit from low level optimization.
Many of the people who work on GCC are scientists who want tight loop performance while many of the folks who work on clang want a BSD license.
As usual, the only reliable way to know which compiler generates better code for your program is to run benchmarks.
For what it's worth, I wasn't blown away by the compile times or error messages when I moved to Clang. I think GCC is getting a lot better, but I'd also learned to live with its failings regardless.
Performance-wise though I still generally get ~5-15% better speed on generated code with GCC (corei7).
It lets you interpret C and C++, if you want.
It lets you compile in C, C++ to bytecode like java if you want, native code if you want too.
D: It is huge for a compiler. I believe gigabytes or so.
"One of our main goals for GCC is to prevent any parts of it from being used together with non-free software. Thus, we have deliberately avoided many things that might possibly have the effect of facilitating such usage"
It's not "doing something extra" to release with BSD; the "doing something extra" comes when you want to properly release with GNU.
After a long random walk over the licensing attitudes graph, I have found myself for the last several years stably located at one node. This node is, "licensing is about lawsuits." People often release with the GNU GPL because licensing, for them, is not about lawsuits but has some other import and use -- perhaps moral. But for me, a license is strictly about defining what sorts of lawsuits are possible.
Copyleft is a threat to sue. More precisely, it is the threat "I may sue you if you don't threaten to sue others." And that just sounds crazy. Why would you do that? Well, the stated goal of copyleft is to eliminate all fears of lawsuits by using legal threats.
Let me hasten to add that this is a very pretty idea. If you know the religions of India, this idea is called tantra -- that sometimes the most precise tool for removing a thorn is other thorns, or sometimes the best way to remove dirt from your clothes is with an abrasive substance -- like other (cleaner) dirt. The reason that Stallman is sometimes described as religious may come back to the attendant mysticism that tantric approaches usually bring with them.
My point is, this sort of thinking is an active choice and requires you to enforce the threat, at least in principle. The BSD license is much simpler: it says "I won't sue you, and you're not allowed to sue me." It is a Buddhist-nonviolence approach to eliminating lawsuits: "I have stopped causing suffering in this world, Angulimala -- now why don't you stop?"
It is nothing extra to release this way: you simply promise to not sue anyone, and you only give permission conditional on the fact that they will not sue you, you write it once and then it is done. It's clean and elegant. If you want to actually be a productive GPL licenser, you have to either hope that the threat in the docs is enough, or else find everybody who is "conveying" your software, and slap them with a lawsuit so that they learn how much lawsuits suck.
Furthermore when you talk about 'promising not to sue', as we see today the highest risk of being sued for software is through software patents. GPL says that if you distribute your patented code under GPL you are not allowed to turn around and sue people using that code or any derivates of it. The BSD licence makes no such provisions and as such you could release patented code under BSD and the proceed to sue people using it.
However, the game theoretic consequences of absolute non-violence (as in Jainism) are negative, unless non-violence is adhered to by everyone in the neighborhood. Or, I suppose you could say instead that non-violence is not a principle to be taken alone. In order to be effective and safe, you have to divest yourself of anything worth stealing, avoid creating interpersonal problems, and stay out of environments where you might be caught up in unrelated violence.
Since copyright has no meaning in isolated or pure environments like that, the analogy breaks down. Copyright is fundamentally a social and legal construct, not a philosophical one.
It's not quite accurate to draw the comparison with a 2-clause BSD license though. Relinquishing copyright and placing code into the public domain would be more pure. Authors licensing code under a 2-clause BSD license are threatening to sue if proper attribution is not kept. 3 and 4 clauses licenses add more promises to sue under some conditions.
This is a lovely way of explaining the difference, and it'll be what I link people to in future when explaining why I opt for BSD-style licensing. Thank you.
The right to do whatever the hell they want with the code is granted by the BSD license. I wouldn't say the same for the GPL.
By licensing code under the GPL, you grant the end-user the right to use and modify any program using your code as he sees fit (as long as he adheres to the rules of the GPL on re-distribution), and no intermediate developer can legally take that right away.
Of course this restricts the freedom of indermediate developers, but the GPL is intentionally -Ouser, not -Odeveloper. It just so happens that some users are also developers.
The right to receive a copy of the implementation of the program they are using and re-distribute it freely.
I say "right" here, because in the case of BSD source on the internet it could be more accurately coined an "election" to distribute the source. As you say, "whatever the hell you want." Which is fine. So is requiring copies to carry a complete copy, including the human-readable form, and the rights to redistribute those, ala GPL.
That would be public domain, not BSD, by the way.
A license can provide a strong indication of your wishes even if you don't ever intend to sue. I don't think it "requires you to enforce the threat" to be effective as a signal to others, particularly companies.
Now, you could say putting a note that isn't part of the license would have the same effect, but I find that hard to believe.
FreeBSD apparently have no issues with donating their work to corporations.
Seconds, there is no "stealing". They provide a license that explicitly allows such a use.
An example: http://openbsd.org/lyrics.html#43
You can even download an MP3 or Ogg of it being sung (With backing.) by Nikkos Diochnos.
> Distributing free software is an opportunity to raise funds for development.
> Don't waste it!
Also, I don't mean to implicate that you share beliefs with the OpenBSD people, since you are merely reporting on their position -- accurately, in my mind. But I thought this is an interesting bit of related information for the discussion.
FreeBSD is pretty much neutral on the GPL, but BSD licensed software is sort of their "thing", so it's natural they'd prefer a BSD licensed compiler.
NetBSD used to be pretty hostile until control was wrested from wasabi systems which disliked the GPL because it prevented them from closing down GPL software.
Dragonfly never really took a position, so it's safe to assume they're neutral too.
That leaves only the OpenBSD guys, of whom (some of) the vocal part thinks anything not OpenBSD is a joke.
I think that's a bit more of a qualifier than "The BSD guys", most of which don't particularly care about phasing out GNU (even though that happens when accumulating BSD licensed software in their OS), some of which are sympathetic but simply like BSD systems more, and what seems to be a fringe minority which is actually hostile for one reason or another.
>Richard felt that this "ports tree" of ours made OpenBSD non-free. He came to our mailing lists and lectured to us specifically, yet he said nothing to the many other vendors who do the same; many of them donate to the FSF and perhaps that has something to do with it.
See here for example:
Stallman and the FSF apply the same standard everywhere. He rejects Red Hat (a major GNU sponsor) as "non-free" just like OpenBSD, in contrast to what the BSD guys claim.
>Richard has personally made sure that all the official GNU software -- including Emacs -- compiles and runs on Windows.
What?! Most official GNU software does NOT run on Windows.
to complement this story a little. rms had heard from one source or another that OpenBSD was "completely free" too (probably based on their hard and much appreciated work on wifi drivers and blobs), and looked into the matter to see if it could be included in the list of FSF endorsed operating systems (which thus far have only GNU/Linux systems).
He found references to non-free software in the ports tree and wrote to the openbsd mailing list to ask for clarifications.
There were actually a few saner voices who politely stated that was the intent and that OpenBSD as a project had a different definition of "free" and as such should not be included in the officially endorsed FSF-list.
Of course, for the less stable elements, it was a good pretext to scoff and insult the the man. Some even riled on and created a song about it. OpenBSD is a fine operating system, but for a normal person the culture around it can be quiteoffputting.
Needless to say, the BSD guys aren't really fans.