Plug-In Architecture On the Way For GCC

VonGuard writes "This year marks the 25th anniversary of the GNU Operating System. A major part of that system has always been the GNU Compiler Collection. This year, some of the earliest bits of GCC also turn 25, and yet some of the collection's most interesting years of growth may still be ahead. The GCC team announced today that the long-standing discussion over how to allow plug-ins to be written for GCC has been settled. The FSF and the GCC team have decided to apply the GPL to plug-ins. That means all that's left is to build a framework for plug-ins; no small task to be sure. But building this framework should make it easier for people to contribute to the GCC project, and some universities are already working on building windows into the compilation process, with the intent of releasing plug-ins."

Comments

So why do I want plugins in my complier?

[NobleSavage]

Can someone explain what kind of plugins might be made? What extra functionality wold I want in a compiler?

Re:So why do I want plugins in my complier?

[Anonymous Coward]

And there are tons more use cases than that! My research group has a complete plugin system already implemented for GCC, and I've written a few plugins for it.

I've got plugins that put hooks in for all sorts of variable access, function call and lock events so I can put in custom debugging code. My current project involves collecting statistics and detailed logs for these events in the Linux kernel.

Because the compiler knows so much data-flow and type information, we also think that these plugins could be perfect for sophisticated static analyses.

Also, it's funny that another poster suggested trippy visualizations, since one of the projects in the group just so happens to be a visualization! It's not the trippy kind though. Actually, it shows you control flow graphs after compilation and lets you drill down into the compiled representation (a 3-address code known as GIMPLE). It's designed as a tool to aid in debugging new plugins, but it may also be useful for people who want to learn about compilers or people trying to figure out how to write code that optimizes better.

Check out the paper:
http://www.fsl.cs.sunysb.edu/docs/gccplugins-gccsummit2007/index.html

GPL to plugins?

[jpmorgan]

Does this mean they want to force all plugins to use the GPL? How is that possible? I was under the impression that the GPL is purely a distribution license. It comes into force when you distribute software licensed under it, and requires you to distribute (or make available) source code and other things.

If I write a plugin and do not distribute it with GCC, what legal basis do they have to force me to GPL it? Nothing I distribute is copyrighted by the FSF, and so how can their distribution license apply to my code? I'm confused.

Re:GPL to plugins?

[againjj]

More precisely, the exception states that if the end compiled product is built with non-GPL compatible plugins, then the end compiled product is subject to the licenses of the linked libraries using the exception. As at least some of those linked libraries are subject to the GPL (being part of GCC) then the end product will be subject to the GPL. If you want to propagate (distribute) the end compiled product, it needs to be a GPL-compatible program, which then means that any libraries linked with it need to be GPL-compatible too, which prevents proprietary libraries linked in. If you do not propagate the end compiled product, then no problem.

So, long story short, if you have a non-GPL plugin, then either (1) the plugin must be GPL-compatible, (2) the plugin can't affect the end compiled product, or (3) the compiled program must be GPL-compatible and not be linked with anything non-GPL-compatible (say, a proprietary plugin). Basically, they want to prevent plugin writers the ability to lock down a GPL program by requiring that it be compiled with the proprietary plugin. I think there is a loophole in (3), so I hope I did not misunderstand it.

Re:GPL to plugins?

[Bruce Perens]

This is really bad advice. If your plugin is not distributed with the GPL software, it's still a derived work.

Re:GPL to plugins?

[QuantumG]

Sorry for the multiple replies.

Friend of mine once pointed out that practically the whole "let's GPL the library so any apps that use it have to be GPL too" strategy has been thoroughly dismantled by the BSD community.

Consider libedit. It's a BSD-like licensed replacement for libreadline - RMS's favorite example of "strategic" non-use of the LGPL. It's binary compatible with libreadline. So you can create your app and link it to libedit and happily distribute it under the BSD. To claim that libedit is somehow a derived work of libreadline because it has the same binary interface would be absurd. However, many installation scripts make a symbolic link from /usr/lib/libedit -> /usr/lib/libreadline.

That's the strong case for dynamic linking == derivative work.. plugin frameworks have always been the weak case. If the strong case doesn't stand up anymore, how can the weak case?

Don't get me wrong, I don't want to see proprietary plugins for GCC anymore than I like seeing all the proprietary modules for the Linux kernel. But claiming there is some clear legal principle that makes them a copyright violation is a joke.

25 years of ....

[fm6]

This year marks the 25th anniversary of the GNU Operating System.

No, this year marks the 25th year of work on the GNU OS. There is still no GNU OS as such, and it's pretty obvious there never will be.

I'm not saying that there's nothing to show for all that work. The GNU libraries and many GNU utilities are key components in many projects, not the least of which is Linux. (<Sarcasm> Oh, excuse me, GNU/Linux.</Sarcasm> ) These are real achievements, and so is the introduction of a new collaborative model of joint software development.

But the original goal of GNU, to create a free alternative to Unix, has never been achieved. No big loss, there are other free Unix alternatives and even true Unixes for free. I just wish that GNU and its fanboys would stop and ask themselves why they never achieved their primary goal.

Re:25 years of ....

[Creepy Crawler]

That's because it takes thousands of people to make an OS.

Look at Microsoft and their lines of OSes.. They have what, 50k people on staff at any one time with perhaps 2/3 of them doing programming work? Most of their code is already written from buy-oughts, so they now provide mostly maintenance and scripting. There's maybe 20-50 people doing *interesting* stuff at any one time, it being 10 years away.

Look at OSX now. They have a similar issue, but leveraged theirs away by choosing a FreeBSD-like platform which to design everything on top of. They also reduce features for their core GUI programs to reduce testing and errors. They also focus much more aesthetically, in direct comparison to Linux GUIS and Windows. And their equipment is much higher priced (can buy 2-3 laptops of the same quality of 1 mac laptop), considering they discourage Hackintoshes.

The Linux guys ad to design everything from the ground up, because of the choice in license. It was also a NiH kind of "I can do it better" kind of game, because Linux was new and exciting. But development still requires large resources. Linus happened to be the appropriate coder/manager to herd the cats at the bottom. Then everything else fell into place: some by luck and others by necessity.

FreeBSD: Its THE academic system, and it works well. It's a traditional fork from SYS I which they license it very openly. There's work done on it, but the "cool" work is Linux. The BSD's are perfect for stability, file sharing, and network code. It has a healthy set of adherents and users, but mostly is relegated to core network technologies.

Now, we look at HURD.. It's there, with a Debian/HURD system install possible. It's there's few device drivers, even fewer developers, doesnt work with basic equipment, buggy as hell (because few developers), and there's something that's "Just As Free", and works to boot (Linux). Would the FSF be better off on discontinuing the HURD? Probably, but it's their choice, and we dont know what its possible uses are yet either.. There's always a critical mass which things like these hit that make them explode, and they might be right about making their own kernel.

Re:That means all that's left is to build a framew

[TheRaven64]

Or just do what the rest of us are doing, and hack on LLVM. It's BSDL, so you can license your plugins however you want, and it's very modular so it's easy to reuse parts of it. Oh, and it's actively backed by Apple, Adobe, Sun, Cray, and a few others including a number of universities.

It's GNU/Linux if it's not uClinux

[tepples]

but trying to run an open source based box without any of the software that gnu has touched is pretty hard

I for one say "GNU/Linux" to distinguish an operating environment designed for a workstation or server from embedded Linux. It's possible to run a useful box, especially one handling embedded style workloads such as IP packet routing, with very little FSF-owned code. A "uClinux" environment might use uClibc or Newlib instead of glibc, uClibc++ instead of GNU libstdc++, and BusyBox instead of Bash and GNU Coreutils.

Nice

[coryking]

Mod me as a troll if you must but... People ought to read the link given by the parent. Wow.

So, how do we permit plugins while prohibiting proprietary plugins, and how do we do it while staying within the bounds of copyright law which is the basis of the GPL

Nice. You know, in a very funny way, the FSF and their jiahad against the evils of proprietary software are basically creating their own twisted form of DRM. Witness this brilliant idea:

most people participating in the related discussions on the gcc mailing list, suggested already that an unstable plugin API would bring all major advantages of plugins in gcc, while complicating the scenario of proprietary plugins. Indeed, it would probably even make sense to consider having a default policy of the plugin API to be modified for each major release, this could be achieved using automated scripts-which would also increase the motivation for plugin authors to keep their plugins in the main repository

Nice. The Linux kernel guys did this and look at the result--it is a bitch for hardware guys to write drivers for Linux. I'm sure deliberately altering the API with a script will work really well for the GCC guys! Makes me want to participate. Not! In truth, it makes me feel like I'm some kind of criminal--only guilty until proven innocent.

Sadly, the FSF did some very nice things, but I think they are becoming so extreme they are going to marginalize themselves and fade away. You know what the biggest hurdle for the BSD guys go separate themselve from GPL? The compiler. The compiler really is the last bit of power the FSF holds over the open source world as a whole. Pretty much every other bit of the toolchain has been replaced with a non-GPL lisence except a good compiler.

LLVM seems to be coming along nicely with major players backing it. I'd be pretty nervous if I was the FSF.