This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Converting the gcc backend to a library?
- To: gcc at gcc dot gnu dot org
- Subject: Re: Converting the gcc backend to a library?
- From: Edward Jason Riedy <ejr at CS dot Berkeley dot EDU>
- Date: Mon, 10 Jan 2000 14:00:11 -0800
And Jeffrey A Law writes:
-
- The basic idea is if there is an IR that can be read/written, then it
- becomes possible for people to write proprietary front-ends, optimizers
- & backends which communicate with GPL'd code via files using that IR.
Um, am I the only one who's seen an obviously gcc executable (the main()
called when you run gcc) connected to a frontend derived from an Edison
Group frontend and an proprietary backend that happens to have many of
the same variable dependency bugs as that version gcc?
In other words, this already happens. And it didn't seem terribly
complicated, although I obviously didn't have the source.
otherwise:
It would be really wonderful to use all the work that's gone into gcc
as a start for a dynamic compilation environment. Not having to re-
invent the wheel is the main point I make when describing free software
to people... (Using gcc for dynamic compilation would require (imho)
some serious re-working of its internals, so a fork might be nice just
so gcc itself isn't trashed in the process.)
However, dynamic compilation itself raises some fun licensing points.
Does this involve linking for some definition of linking? If so, is it
even possible to have, say, a GPLed Java package that implements an
object that can be trasmitted over a network? What if the Java
implementation knows the other side is the same architecture and sends
the binary code? Under what circumstances would this violate the GPL?
I admit that this is a somewhat contrived example, but not impossible.
Jason