This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Converting the gcc backend to a library?


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]