Quoting Kyle Girard <k...@kdmanalytics.com>:
A generic linked-in plugin ability would definitely solve my plugin-on-windows problem. From what I've been reading on this list it looks like I'm going to have to do some sort of similar hack to gcc to get my plugin working on windows at least in the short term.
I hacked GNU hello 1.3 a little to make it work as a linked-in GCC plugin, thus bringing much needed mail reader funtionality to GCC. Well, at least on unix-like systems with mailboxes it does. So during configuration, I added: --enable-link-plugins=all alternatively, it should be possible to specify a list, although I haven't tested this. When you've built your compiler, you can access the GNU hello functionality via -fplugin / -fplugin-arg:[amyl...@laria gcc]$ ./xgcc -B. -fplugin=hello -fplugin-arg-hello-h -x c /dev/null -c
This is GNU Hello, THE greeting printing program.
Usage: -fplugin=hello
{ -fplugin-arg-hello([h[elp]] | [t[raditional]] | [v[ersion]] | [m[ail]]) }
h[elp] Print a summary of the options
t[raditional] Use traditional greeting format
v[ersion] Print plugin version information
m[ail] Print your mail
[amyl...@laria gcc]$ ./xgcc -B. -fplugin=hello
-fplugin-arg-hello-sailor -x c /dev/null -c
Nothing happens here. The attached patch still has some rough edges, like missing main gccChangeLog, missing documentation, no dso building implemented (should eventually work both in-tree to be installed in the plugin dir and
out-of-tree with a previous built compiler).I though it'd make sense to ask first if the patch so far goes in the right direction.
link-plugin-diff.bz2
Description: BZip2 compressed data
