[gcc plugins rely on ELF features and therefore don't work on MS windows]
Quoting David Brown <da...@westcontrol.com>:
In reality, if embedded developers are unhappy (for whatever reason) with running gcc on Windows, they will move to proprietary compilers under windows - not gcc on Linux. Of course, this is not a problem at the moment - gcc plugins are currently only for particular special purposes and specially interested developers and users, and so requiring Linux is not a big issue. But as gcc plugins become more mainstream, it will become a limitation. Should the famously cross-platform, cross-host, cross-target gcc now be limited to specific hosts?
The main utility of plugins is that they make developing, testing and deploying modifications to gcc easier. I don't think that MS windows users will miss too much if they can't dynamically load the plugins, as long as their sysadmin can provide them with a linked-in version - the sysadmin might actually be happier about the greater control, as plugins are potential virus/trojan vectors. It makes sense to write a plugin in such a way that it can alternatively be used as a GCC patch - in the sense that you add the code alongside the main gcc code and it gets linked in. Maybe we should create an interface for linked-in plugin code, i.e. arrays of plugin names and their plugin_init function so that they can be activated with a matching -fplugin=built-in:NAME (or propose a different syntax if you think of a better one) and get passed any plugin options like a dynamically loaded one would. The plugin_init function name would of course have to be mangled or put into a namespace to avoid clashes with other plugins.
