A revised GCC runtime library exception

[Posted April 1, 2009 by corbet]

The Free Software Foundation has posted a revised version of the new GCC runtime library exception. There's no description of the changes, but the new text is short and easy to read. Essentially, it seems to specifically equate Java virtual machine code with human-readable languages, meaning that Java byte code can be processed through GCC and still link against the runtime library.

A revised GCC runtime library exception

Posted Apr 1, 2009 15:41 UTC (Wed) by clugstj (subscriber, #4020) [Link] (1 responses)

It seems weird to me that they call out Java bytecode specifically. There are other equivalent "virtual machine code" formats, what about them?

A revised GCC runtime library exception

Posted Apr 1, 2009 17:18 UTC (Wed) by glennc99 (guest, #6993) [Link]

They call Java byte code out because the "Gnu Compiler Collection" includes a native Java byte code compiler, but they got off of the Java source language treadmill by using the Eclipse Java Compiler, which (as I understand it) isn't GPL.

So they needed to tweak the new runtime exception to let them keep shipping Java.

A revised GCC runtime library exception

Posted Apr 1, 2009 23:17 UTC (Wed) by rriggs (guest, #11598) [Link] (4 responses)

How does this affect Sun's GCCfss, which takes GCC intermediate representaion (IR) and feeds it into the Sun Studio backend?

http://cooltools.sunsource.net/gcc/4.2.1/ReleaseNotes.html

If I read this right, any binary that is compiled with GCCfss, because Sun's implementation would not appear to be an "Eligible Compilation Process", can only be distributed under the GPL. They don't notify developers of that at all in their GCCfss documentation.

A revised GCC runtime library exception

Posted Apr 2, 2009 0:21 UTC (Thu) by davecb (subscriber, #1574) [Link]

Only if it's linked by gccfss, which
arguably isn't the case.

--dave

A revised GCC runtime library exception

Posted Apr 2, 2009 0:32 UTC (Thu) by JoeBuck (subscriber, #2330) [Link]

IANAL, of course.

The license change will only affect use of future versions of the GCC runtime libraries, but yes, Sun's approach does not qualify for the exception, so anyone using that approach, or a similar approach that passes converted GCC IL through proprietary code, will not be able to use the FSF's libraries from 4.4 onward (libgcc and libstdc++) except with GPL-compatible software. They'd have the option of continuing to use older libraries that were released with the older license, so in the short term that's an easy workaround. And nothing in this change applies retroactively to anything the FSF has already shipped.

GCC has long wanted to support plugins, but the FSF was worried that opening up the architecture would just get people adding proprietary passes to GCC using the IL as a communication mechanism. So this is the deal. It took about a year and a half to go through.

A revised GCC runtime library exception

Posted Apr 2, 2009 17:35 UTC (Thu) by stevenb (guest, #11536) [Link] (1 responses)

IANAL, but to be honest, I actually hope this new license exception makes life harder on GCCfss. I consider this kind of hack-around-the-GPL compilers pure theft. Sun originally started GCCfss, IIRC, because GCC-for-SPARC was not doing a good job. But if Sun wants better code from GCC for their architectures, they should just work on improving the FSF GCC, like almost all other significant chipmakers (Intel/AMD/IBM/ARM/STM/...) do.

A revised GCC runtime library exception

Posted Aug 26, 2016 0:56 UTC (Fri) by rlhamil (guest, #6472) [Link]

IMO it's not that simple.

Sun CC vs GCC differences (AFAIK) include:
* command line option differences (differences reduced in newer versions, to help ease Makefile pain)
* the input language (extensions and embedded compiler directives)
* the C++ linkage conventions (name mangling, virtual function tables, RTTI, etc)
* the better performance of code from the back-end of the Sun compiler on SPARC

Performance is only ONE of the gains with a hybrid. The other is that open-source code all too often effectively written for gcc rather than for the published language standard, may be less painful to compile on gcc; and that vendor C++ libraries can be linked with using either the proprietary or the hybrid compiler, rather than using as a substitute binary-incompatible (and not necessarily identically functional) open-source libraries.

Granted that the ideologues see the universal ideal of ALL code being open, I think they don't live in the real world. Binary compatibility may be important to customers...and published standards OUGHT to be important to developers (rather than the sloppiness of writing to a specific compiler).

The GCC front end modifications have AFAIK been published, and are on source forge. So I don't buy the "theft" argument at all. And I have no use for ideology when it gets in the way of doing something useful...a situation that's bound to arise more and more often with virtualization, embedded devices, and all sorts of situations other than the traditional general purpose box.

A revised GCC runtime library exception

Posted Apr 2, 2009 22:30 UTC (Thu) by emk (subscriber, #1128) [Link] (1 responses)

Does anybody know how this will affect LLVM?

A revised GCC runtime library exception

Posted Apr 7, 2009 18:14 UTC (Tue) by stevenb (guest, #11536) [Link]

I think this won't mean anything for LLVM, and I don't have to look at this new license change for that. Apple stays away from any GPLv3 code, so even GCC 4.3 is a no-no for them. This change affects only GCC 4.4. and newer, and not the GCC 4.2 based LLVM-gcc. Likewise for Open64, btw.