LLVM & GCC Compiler Developers To Begin Collaborating 279
An anonymous reader writes "While RMS is opposed to LLVM over its BSD-like license rather than the GPL, LLVM/Clang and GCC developers have agreed to try to start cooperating in an "open compiler initiative" to jointly tackle common issues that plague both compilers and issues that can be better served by working together rather than creating fragmentation between the two popular open-source compilers."
altslashdot.org (Score:1, Insightful)
http://www.altslashdot.org/
in case y'all didn't know.
#F...BETA
RMS needs to get over the GPL (Score:3, Insightful)
The GPL is not for everyone or every company, get over it.
The BSD[MIT/APACHE/ZLIB] licence is the only real free open source license. In a perfect world we wouldn't need licences at all and everyone wouldn't have a hissyfit every time someone borrowed code from someone.
Re:Open borders... one way? (Score:5, Insightful)
For example, the pretty huge list of C and C++ extensions that both gcc and clang implement, and that are invented by the authors of said tools. It's much better that the two talk about it, and come up with one spec that both compilers implement than to have two competing standards that results in code one or other compiler can't deal with.
Re:Open borders... one way? (Score:4, Insightful)
There's a boatload of stuff to agree on for better interop. The language itself (c/c++) says nothing about a lot of stuff people kind of expect these days.
Language extensions specific to compilers (e.g. __user), toolchains (e.g. llvm is working on lld, a linker, to replace the default system linker), security additions (e.g. if I build a library with gcc and specify stack protection and canaries, none of which are in the language standard, will I be able to link a clang built library and executable and actually have it work), etc.
Re:Open borders... one way? (Score:5, Insightful)
Another thing would be to harmonize the representation of fundamental classes like std::string and std::vector, so those classes can be passed between codes compiled with both compilers, even though the implementation code for those classes might otherwise differ.
You are not reading history. (Score:5, Insightful)
I'm not sure how GCC could benefit from this.
You are not reading history.
GCC moves too damn slow and doesn't include features that developers (and more importantly: the companies which pay developers) want. These days, that includes the changes between the GPLv2 and GPLv3 not being wanted by the people who pay the bills.
GCC was more or less started in 1984: http://www.gnu.org/gnu/thegnup... [gnu.org]
GCC was almost replaced by the EGCS fork in 1997, and it took two years before RMS finally gave up on the idea of having the ultimate editorial control over the language implementation, and "blessed" EGCS as the replacement for GCC. When he did that, he gave up on limiting the OSs that the compiler worked on, and limiting the inclusion of things like #pragma (which used to exec "nethack" because RMS didn't like it), and some of the language front ends that are now included, like g77, which RMS didn't want.
GCC is on the verge of being marginalized again by LLVM; all the sexy compiler work is happening in LLVM, all the bright young minds in the compiler world are going to LLVM because it's a lot easier to make a front end for a new language or a back end for a different processor or embedded controller or virtual machine. LLVM is the "go-to" compiler for academic projects involving compiler research.
It makes sense; GCC: 1984; +15 years = EGCS: 1999; +15 years = ????: 2014.
RMS' recent appeal *might* be able to attract a bunch of new ideologues to the GCC project, and have them forsake LLVM work, but more likely course and project requirements for a degree, and after that, an employer, probably mean that LLVM is going to remain the "go-to" compiler for the new blood.
The idea that GCC can leverage some of the new blood by making it easier for them to work with code in both contexts, rather than leaving GCC in the ashbin of history, is about the *only* way to give GCC the transfusion of new blood it's going to need to survive another 15 years.
It also couldn't hurt to expand the number of (or replace) members of the "GCC steering committee" so that GCC can get a little more forward momentum. You can get forward momentum one of two ways: (1) more specific impulse, or (2) take off the parking brake.
Re:RMS needs to get over the GPL (Score:3, Insightful)
The GPL guarantees that if you have access to the binary you have access to the source. BSD/etc do not. In other words: BSD gives you the "freedom" to restrict others freedom. That isn't something people on the free software front consider positive.
Maybe it's you who should get over the fact rms believes in free software. You're entitled to your opinion, he's entitled to his. It isn't like he's pointing a free 3D-printed gun to your face and forcing you to write GPL'd code to extend emacs.
Re:Open borders... one way? (Score:4, Insightful)
Re:RMS needs to get over the GPL (Score:2, Insightful)
GPL = "You better give some something back buddy if you want to use this"
Re:RMS needs to get over the GPL (Score:5, Insightful)
Comment removed (Score:5, Insightful)
Re:RMS needs to get over the GPL (Score:2, Insightful)
They would;t have written it in the first place if GCC hadn't gone GPLv3.
Up until that point they were distributing GCC as their main compiler with Xcode, and used it to build OS X itself.
With the arrival of GPLv3, designed to shut them (and others, like Tivo) out, they had no choice but to move away from GCC. They either had to use a pre-existing compiler (potentially expensive to licence) or write their own, hence LLVM and Clang.
Comment removed (Score:4, Insightful)