This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Plug-ins on Windows
[gcc plugins rely on ELF features and therefore don't work on MS windows]
Quoting David Brown <david@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.