Joern Rennecke wrote:
[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.
I think I am viewing this situation from a different angle from others
on this list. You guys are (I presume) mostly gcc developers - I am
mostly a user, who is interested in the development of gcc and would
like to get involved if I can ever find the time. I am particularly
interested in the "smaller" targets, such as for the AVR - I work as a
professional embedded developer and use several gcc host-target
combinations for my job. I am therefore trying to offer a slightly
different viewpoint here, in the hope that it will be of help or
interest to others.
The fact is, windows sysadmins do not, as a rule, build gcc for others.
In most cases, there are two sorts of people who compile gcc to run
on windows. There are people who build gcc, and package it along with
libraries, debuggers, and other tools in an easy-to-install package for
others to use. Sometimes this is done for fun or interest, sometimes it
is done for money. Then there are the few specially interested users
who build the tools for themselves. For most windows users, the concept
of compiling your compiler is alien. They don't have the required tools
(such as cygwin or mingw/msys, or a Linux machine for cross-compiling),
they are not used to the command line, and they are not used to the idea
of the compiler being separate from the linker, library, and related
development tools.
Another issue is that for embedded developers, it is very important to
have the consistent toolchains, and sometimes to have them certified or
qualified in some way. In this business, often makes sense to pay
someone like CodeSourcery for a build that they have tested thoroughly,
rather than compiling your own build with the latest and greatest
version that hasn't yet had the same level of testing.
So having said all that, it's fairly clear that almost all development
work for gcc is done on Linux (or other *nix-like platforms), and that's
where the development benefits of plugins are by far the most relevant.
But there are plenty of potential uses for plugins beyond development.
There is a lot of scope for plugins that are not tied tightly to
particular compiler versions or targets, and could be decoupled from the
main compiler development. One I mentioned in an earlier post would be
a "ccache" plugin. Others include static analysis plugins, or perhaps
even code style standards checkers. I think it would be a good thing
for everyone if plugins like that could be developed independently of
gcc and distributed as compiled shared library files (as well as the
source, of course) on both Linux and Windows.
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.
