Plug-ins on Windows

[Joern Rennecke]

Quoting David Brown <david@westcontrol.com>:

> But it strikes me that a system where the main programs and the plugins
> are directly linking to each other is going to make it hard to separate
> the development of the two sides, and hard to distribute compiled
> plugins that will work with separately compiled main binaries.  And
> surely it is this sort of separation and modularisation that is the
> whole purpose of the plugins?
>
> For the "average" gcc user running Linux and with a single version of
> gcc producing native code, it doesn't matter much - they've either
> compiled their plugins at the same time as their gcc binary, or (more
> likely) their Linux distribution maintainers compiled them at the same
> time.

No, both binary plugins and their sources are generally much smaller
than the GCC distribution.  And a plugin is built faster from source.
Also, it is often more straightforward to combine different plugins
than to take different patchsets, merge them into gcc sources, and
bootstrap the compiler.

> But gcc is far more flexible than that.  I use gcc for perhaps six
> different targets on a regular basis, with a variety of versions of gcc
> for some of the these targets, with different hosts (Windows or Linux),
> and with different target OSes (mostly bare metal elf, sometimes Linux,
> and some old bare metal coff).  To my mind, a plugin that works for
> gcc-mips-linux-4.5 should work without recompilation for
> gcc-arm-elf-4.6, assuming the same host.

It depends on the plugin.  If to uses target-specific macros or types,
(e.g.: FIRST_PSEUDO_REGISTER, CUMULATIVE_ARGS) or invokes functions
specific to a target (could be autoconfigured), then I wouldn't expect this
to work.  Also, the name mangling has to match.
Still, recompiling the plugin for two different gcc builds tend to be much
more lightweight than to rebuild & install two gcc configurations.

> And it should be possible to
> build the plugin binary for Linux, Window s (native/mingw, not just
> cygwin) and other major gcc hosts (Mac, BSDs, etc.).  Like it or not, a
> great deal of cross-compilation embedded development is done using gcc
> on windows, and it's a shame if something as potentially powerful as
> gcc plugins is not available to those users.

Well, it's their choice (or their employers/sysadmins), we can't force them
to switch to a more powerful development platform.  As you said, there are
a number of major gcc host platforms available, and several elf-based ones
run on the same hardware as MS windows.