| |||||||||||||
A new GCC runtime library license snag?A new GCC runtime library license snag?Posted Jul 27, 2009 21:53 UTC (Mon) by Baylink (subscriber, #755)Parent article: A new GCC runtime library license snag?
I dunno, but it seems to me that the *loser* here is the GCC project, indirectly by way of the pain they're going to inflict on their users by moving to GPLv3.
Sometimes, you can leverage your loving audience into doing the things you want them to do; sometimes not so much. This might be a "not so much" time.
Don't get me wrong: just as in politics, we *need* people at all points in the ideological spectrum: though no one uses the Hurd, if rms hadn't written the GPL to be hardcore enough that companies waste money on lawyers debating whether it will infect their business, then Linux wouldn't be where it's at today; I firmly believe that, and I've been running open source code since my newsfeed came in at 1200bps and I could read all of it.
(Log in to post comments)
A new GCC runtime library license snag? Posted Jul 28, 2009 7:39 UTC (Tue) by rsidd (subscriber, #2582) [Link]
To the FSF, GCC and the other compiler-toolchain programs are the one truly indispensable thing they have contributed: there are other system libraries, other editors, but only one usable free C compiler -- even the BSDs use gcc because there is no alternative. But LLVM/Clang could well change that in the near future (it is already usable for compiling the base FreeBSD system). So the FSF will have to lighten up a bit on GCC, if they want to stay relevant. They already lost one battle when they had to accept the egcs fork and rename it the "new" GCC: but if LLVM catches up with or overtakes GCC, it will be much harder for the FSF to stay relevant.
A new GCC runtime library license snag? Posted Jul 29, 2009 1:22 UTC (Wed) by Baylink (subscriber, #755) [Link]
My understanding of the egcs un-fork didn't characterize it that way; does that mean I drank the Kool-Aid? :-)
A new GCC runtime library license snag? Posted Jul 29, 2009 8:05 UTC (Wed) by rsidd (subscriber, #2582) [Link]
My understanding is that egcs forked because it was impossible to get changes into the FSF tree. Despite ESR's analogy of free software with "the bazaar", the FSF has always had a "cathedral" mode of development. The egcs people did desire eventual re-merging and were careful to assign copyrights to the FSF. Eventually when the FSF realised gcc 2.8 was a dead-end and egcs had leapfrogged it, they agreed to re-merge with egcs and call the result gcc 2.95. But this happened after most serious users had switched to egcs anyway: gcc 2.7.x was showing its age and gcc 2.8 was seriously flaky. So it was bowing to the inevitable, but it wasn't so bad for the FSF, since it was still GNU software with copyrights held by them. The current situation could turn out worse.
A new GCC runtime library license snag? Posted Aug 2, 2009 1:30 UTC (Sun) by landley (guest, #6789) [Link]
Actually, the FSF _was_ the "cathedral" in CATB, and Linux was the "Bazaar". (Eric's said so in a couple interviews over the years, he just didn't play it up in the paper itself so as not to set-off the FSF's supporters.) Eric was comparing different methods of open source development. (Keep in mind that CATB came out shortly before the egcs fork, when gcc development was stagnant.)
Eric got the idea for the paper at a conference in 1996, which is described in some detail here:
A new GCC runtime library license snag? Posted Aug 2, 2009 1:34 UTC (Sun) by landley (guest, #6789) [Link]
People have been looking for a gcc replacement for a while now. LLVM/Clang is one (supported by Apple), and the relaunched PCC is another (supported by a couple of the BSDs, see http://lwn.net/Articles/255558/ for details).
Tinycc was aiming to be a third one, but it died. (The corpse lurches onward zombie-like as a windows compiler, but is unlikely to ever amount to anything on Linux. Alas.)
Rob
A new GCC runtime library license snag? Posted Aug 2, 2009 5:15 UTC (Sun) by rsidd (subscriber, #2582) [Link]
Fabrice Bellard seems to be making releases of tinycc at irregular intervals (the last on May 20, 2009). He also links to your fork. Is it uninteresting because it offers insufficient scope for optimisation? People who want to use C in the first place care more about fast binaries than fast compilation, and if development time (as in compilation time and other things) is more important than runtime speed, there are other and better languages, it seems to me.
A new GCC runtime library license snag? Posted Aug 2, 2009 7:11 UTC (Sun) by landley (guest, #6789) [Link]
> Fabrice Bellard seems to be making releases of tinycc at irregular
> intervals (the last on May 20, 2009).
Fabrice didn't make that release, Griscka did. Fabrice just uploaded it. Fabrice dropped tinycc to work on QEMU, and the project stalled years ago. He still drops by the mailing list about once a year (I believe his most recent post to the list was 15 months ago, and the last post before that was 24 months ago).
Well over half of the work in the .24 release was either stuff done after the previous release back before Fabrice lost interest, stuff I collected and sent to Fabrice back at the start of my fork (back around 2006), or stuff Grischkah ported over from my fork. Grisckha primarily does work on the windows target, not on Linux. (Grishcka literally said that he didn't port of a lot of the work in my fork because he didn't understand it. Not that he'd asked.)
The only real non-Windows work in the .25 release I'm aware of was somebody in Japan popping up out of nowhere with an x86-64 backend at the start of this year, not anything that came from any existing developers on the list. They had a release because somebody dropped an x86-64 target in their laps out of the blue, not because of any work done on the list. (Not that the tcc codebase they're using is 64 bit clean, but you can sort of fake it if you're only building toy programs.)
> He also links to your fork.
My fork's long dead, as explained on the page they (still) link to.
> Is it uninteresting because it offers insufficient scope for
It's uninteresting because five years ago, Fabrice came up with a specific list of things required to build an unmodified (2.4) Linux kernel, and it still can't do it today, and making it do it isn't a goal of the current developers (let alone building 2.6, busybox, and uClibc):
http://bellard.org/tcc/tccboot_readme.html
Note that building a 2.6 kernel is harder than building a 2.4 kernel. The two big pieces of infrastructure missing are variable length arrays and simple dead code elimination, and neither is currently under active development. (I was working on both when they drove me off, now I don't care.)
For a couple years there, I did more work on it than the rest of the tcc development community combined. (Not because I really had time or expertise, but because nobody ELSE was doing it.) Since I left, except for the guy who added the x86-64 target, the rest of the development community has implemented the occasional bugfix. Maybe it's changed in the past few months, I haven't been paying attention, but list traffic was still mostly bug reports from windows people last I checked. (The project's mailing list often went weeks between posts, and the majority of the traffic was about Windows. Not very interesting.)
> People who want to use C in the first place care more about fast
Sure. But the compiler/interpreter/runtime for those languages are implemented in C. If you're creating a self-bootstrapping environment, you need a C compiler.
What attracted me to tinycc is that it was _simple_. The entire compiler is about 100k lines of source, it just needed a huge cleanup and refactoring to be extended to support multiple architecture targets, build a full Linux kernel, be maintainable by anybody but its original author...
What I really wanted to do was refactor tinycc into a busybox-like swiss army knife executable providing "ld", "cc", "as", "strip", and so on so it could properly replace gcc and binutils. It would also be good to look into using qemu's new code generator (tcg) as the back-end rather than trying to maintain a dozen processor targets with a half-dozen variants each.
But the existing tinycc development community has little interest in doing any new work on it. Change to existing code seems to upset them.
The smallest self-bootstrapping Linux system is, theoretically, the linux kernel, uClibc, a swiss-army-knifed tcc, and busybox extended a bit to include things like "make" and a bash replacement sh. Alas, in the past 5 years we haven't come noticeably closer to that happening.
Rob
|
|||||||||||||