Originally posted by mark_
View Post
Announcement
Collapse
No announcement yet.
Using LLVM As The Compiler Within Fedora?
Collapse
X
-
please stop quoting freedom
-
In all this discussion I seem to agree with some things; others, I think it's just a waste of time.
For example, discussing freedom. In general, I'd bet no two persons have the same definition of freedom. Even if we have 2 GPL-persons they'd surely at some point diverge. It's just a matter of what is freedom to you. Personally, I find the BSD 'total freedom' paradigm more attractive and it adjusts to my personal feelings about what freedom should be. As Benjamin Franklin said, "Those who would sacrifice freedom for security deserve neither". But that's me, and whatever alternative definition for freedom is equally valid.
Whether GCC, Clang, etc, are closed or 'less free' than whatever is about equally subjective; I think one can give his opinion but not dictate what it should be (aren't we free to choose what freedom is?).
So, facts are:
1) GCC has a lot of features Clang/LLVM still lack.
2) Clang/LLVM is an exciting project which promises not only to be as feature-rich as GCC (is this true?), but also to deliver new possibilities (for example, those implied by the BSD license).
Further extending these two premises one can discuss whether it is justifiable to do an enormous amount of effort just to change platforms (for example, as FreeBSD pretend to do). This, again, depends on our own philosophy (it might be justifiable for the BSD side, but not for a Linux distribution).
Leave a comment:
-
Originally posted by yogi_berra View PostYes, why don't you?
Right... but only within GCC or a GPLv3 compiler which means, of course, GCC. How is that not platform specific again? How is that not closed? How is "do it my way or don't do it at all" free?
The GPL is about END USER FREEDOM and stopping unscrupulous middle men from taking that freedom away. The BSD license is about DISTRIBUTOR freedom, specifically, giving the developer the freedom to take away the user's freedom.
When the Apple meat puppets over at FreeBSD call their license more free than the GPL, this is what they mean.
As a user, I have to say I'd rather side with the license that guarantees freedom for me. Of course, developers that just want a free handout don't like the GPL, why would they? It stops them from abusing the end user and burying free software inside proprietary software.
Back to LLVM. If it was better than GCC for the purposes of building binary object code, then there's no ethical problems with redistributing it. But I would hope that someone would fork it and wrap the GPL around it to prevent freeloading proprietary software from making use of those improvements.
There's nothing wrong with using software under a permissive license, though permissive licenses are usually a form of corporate welfare. (Either the project is ran entirely by some corporate entity or there's a horribly mistaken programmer that is working for free to help build the next OS X.)Last edited by DaemonFC; 18 February 2012, 10:28 AM.
Leave a comment:
-
Originally posted by yogi_berra View PostRight... but only within GCC or a GPLv3 compiler which means, of course, GCC. How is that not platform specific again? How is that not closed? How is "do it my way or don't do it at all" free?
And how the **** do you get from a specified extension which ANYONE can implement to claiming that it is CLOSED????? Not to mention that both GCC and Clang/LLVM are both free to download and use, no matter what platform you are on.
You are a troll, none of your statements have any reasoning behind them. It's like listening to a 5 year old throwing a tantrum.
Leave a comment:
-
Originally posted by yogi_berra View PostRight... but only within GCC or a GPLv3 compiler which means, of course, GCC. How is that not platform specific again? How is that not closed? How is "do it my way or don't do it at all" free?
Leave a comment:
-
Originally posted by XorEaxEax View PostJust stop trolling,
first off the extensions are not platform specific, you can use them on Windows aswell
Leave a comment:
-
Originally posted by mark_ View PostXorEaxEax: The essence of your posting is, that the gcc language set has to be treated like a language standard (which it is NOT; it might barely be an unofficial one). So every programmer that uses these extensions, forces the users to use that compiler too and depending on your definition of freedom, this makes the users less free than before (example: the BSD guys). This is equal to like using a non standard library in your program (think of early KDE days: KDE was free, Qt was not).
I claim that it might be very convenient for the programmer to choose such extensions, but as I said, there is a price.
Basically, I could sit down for about six weeks and write an absolutely minimal C compiler that just baaarely supports C89 (and without any of the optional features of the C89 standard, and with a huge amount of variance in the behavior of undefined behavior situations compared to existing compilers such as gcc). I could claim full C89 standards compliance. But in practice, most large programs have at least SOME code that relies upon undefined behavior if you strictly go by what the standards say. So if my crap compiler decides to, I don't know, panic the kernel whenever it finds undefined behavior, that's perfectly fine with the standard. But it wouldn't be perfectly fine with me as a user.
If I then show you my standards-compliant compiler and ask you why your perfectly C89-compliant code panics my kernel, would you then be obligated to fix your code so that, when compiled with my compiler, it works properly? No, I don't think I'd be entitled to ask that of you, as the compiler author.
The same situation is true for LLVM and supporting GNU C extensions. If "you" (as someone who values LLVM/Clang) want to improve your compiler-of-choice's ability to compile correctly-operating programs that were written by third parties which do not particularly value your compiler compared to any other, you have two options:
1. Submit patches to the application code to make it compatible with your compiler, and follow any directions given to you by the application maintainer to implement e.g. conditional compilation directives, so you don't screw up the performance or functionality of existing compilers that they target.
2. Submit patches to your favorite compiler's code to make it compatible with your application, by mimicking the behaviors of the officially supported compiler(s) that cause the program to successfully compile and run.
You should not expect someone else who is maintaining a free software project to do this work automatically for you, especially if they have no particular interest in the use of your favorite compiler. It is not your prerogative to place work on others' shoulders just to satisfy your own personal demands. If you want it done, the best way is to do it yourself, or work among a group of like-minded peers and developers who are interested in the same goal.
I just think that this whole argument about standards compliance is missing the point. "Standards" are an illusion in software. There is always going to be some loophole, some piece of undefined behavior, some detail left unspecified, in every human-created standard, and in every human-created program code. As the complexity of the standards and the complexity of the code together increase, the probability of hitting said undefined behavior asymptotically approaches 1.
So, assuming that X compiler is going to have some issues compiling or producing correct binaries for Y program, coming down from on-high and citing standards isn't going to be an effective approach, because standards aren't the only thing that can cause incorrect behavior. Instead of clinging to "but the standards!", you need to get involved in the actual nitty-gritty politics of the situation, and try to convince people that they SHOULD care about your personal compiler, and they SHOULD want to help you patch their application code (or, respectively, your compiler's code) so that the compiler plays nicely with the application and vice versa.
Compatibility is not a one-way street, especially in the free software world; and there is no magical appeal to authority that can be used to convince others that they ought to do what you say. Instead, you need to build bridges, form alliances, and create mindshare for your agenda. If you can't do that, maybe it's because, oh I don't know, your compiler is substantially slower than the de facto solution, so nobody thinks it's worth worrying about right now?
Well, there's that, and there's also the notion that GPL purists (or even those who aren't strictly GPL purists but just dislike liberally-licensed free software licenses) might resist LLVM just on principle. And I think that is an entirely fair thing to do, because it brings to light a real disagreement and a material discrepancy of opinion, something that you can't avoid by just waving the standards flag around like a lunatic.
Leave a comment:
-
So to sum it up, Fedora isn't using LLVM because:
1. It wouldn't compile a lot of packages, including the kernel.
2. When it does work, it tends to generate worse output than GCC.
3. It generates less useful debuginfos.
As well as (implied)...
4. Let's not introduce Apple dependencies on a Linux distribution. Apple makes money by court injunctions against competitors, not making better products. Why would we want free software to depend on a rent seeking patent troll like Apple?
Leave a comment:
-
Yep, and Clang doesn't yet do static analysis for C++. Eagerly waiting for that to happen though.
Leave a comment:
-
Originally posted by XorEaxEax View PostNot me, I can do with a simple editor but I require a good compiler toolchain, not sure what you mean by tools.
I think this is what he is referring about.
Anyway, I do think as GCC is the backbone of too many software, I fully agree with you, LLVM make little sense out of some specific targets and OS X realm, maybe as a better code generator for Mono runtime.
Leave a comment:
Leave a comment: