The attached patch still has some rough edges, like missing main gcc
ChangeLog, 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).
Well, I definitely owe you some beer.
Joern Rennecke wrote:
The main utility of plugins is that they make developing, testing and
deploying modifications to gcc easier.
This may be true now, but I certainly hope it will not be true in future.
I view the current plug-in mechanism as a prototype. I think that we
should be working
I view the current plug-in mechanism as a prototype. I think that we
should be working toward a much more robust mechanism, similar to
plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks.
I certainly see no reason that plug-ins cannot work on any system that
has something
On 6 July 2010 17:54, Grigori Fursin gfur...@gmail.com wrote:
I view the current plug-in mechanism as a prototype. I think that we
should be working toward a much more robust mechanism, similar to
plug-ins for Eclipse, Firefox, MySQL, or other popular software stacks.
I certainly see no reason
[mailto:ctuning-discussi...@googlegroups.com] On Behalf Of Manuel Lopez-Ibanez
Sent: Tuesday, July 06, 2010 6:42 PM
To: Grigori Fursin
Cc: ctuning-discussi...@googlegroups.com; Joern Rennecke; David Brown;
gcc@gcc.gnu.org
Subject: Re: Plug-ins on Windows
On 6 July 2010 17:54, Grigori Fursin gfur
On 6 July 2010 23:05, Grigori Fursin gfur...@gmail.com wrote:
I don't disagree with your comments too, Manuel.
I spent some years developing plugin framework for pass selection and
reordering, and later we managed to get minimal hooks to mainline GCC based on
our needs. Of course, I
Manuel López-Ibáñez wrote:
So I would prefer that GCC developers do not say We want to provide
an API when what is actually meant is We will be happy if people
contribute patches towards providing an API.
OK, I agree with that. As far as I know, nobody right now is actively
working on
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
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
On 01/07/2010 00:46, Dave Korn wrote:
On 30/06/2010 21:38, Kyle Girard wrote:
Hello,
I am playing around with a plug-in for gcc but recently ran into the
road block that plug-ins aren't supported on Windows. Are there any
plans to add support for the windows platform in the future? If not,
Quoting David Brown da...@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
On 1 July 2010 12:14, Joern Rennecke amyl...@spamcop.net wrote:
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
On 01/07/2010 12:14, Joern Rennecke wrote:
Quoting David Brown da...@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
On Thu, Jul 1, 2010 at 2:48 PM, David Brown da...@westcontrol.com wrote:
I was perhaps over-generalising - obviously anything that depends on target
specifics will be dependent on the target. And I'd also expect some things
to change in the plugin interface between major gcc versions - while
Quoting Richard Guenther richard.guent...@gmail.com:
Re-compiling the same plugin sources for different gcc versions is
not supported. Of course you might be lucky for minor version
changes such as 4.5.3 to 4.5.4.
I think that's putting it a bit too strong. If the maintainer of a plugin
On Thu, Jul 1, 2010 at 3:23 PM, Joern Rennecke amyl...@spamcop.net wrote:
Quoting Richard Guenther richard.guent...@gmail.com:
Re-compiling the same plugin sources for different gcc versions is
not supported. Of course you might be lucky for minor version
changes such as 4.5.3 to 4.5.4.
I
[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
On 06/30/2010 04:21 PM, Jan Hubicka wrote:
Long term we could arrange for libbackend.a to become libbackend.dll and
have that library be used for plugins. The existing practice of linking
back into the main executable is more or less an efficiency hack that
happens to work with ELF.
It
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 -
Hello,
I am playing around with a plug-in for gcc but recently ran into the
road block that plug-ins aren't supported on Windows. Are there any
plans to add support for the windows platform in the future? If not,
what are the issues with supporting Windows and how much effort would it
be to add
On Wed, 2010-06-30 at 16:38 -0400, Kyle Girard wrote:
Hello,
I am playing around with a plug-in for gcc but recently ran into the
road block that plug-ins aren't supported on Windows. Are there any
plans to add support for the windows platform in the future? If not,
what are the issues
Quoting Kyle Girard k...@kdmanalytics.com:
Would it be a lot faster/easier to create a custom gcc that
has my plug-in compiled in directly for the windows platform?
Depends on how many plugins you use.
The distgcc page says it's reported to work on cygwin.
So you could use a cygwin distgcc
On 30/06/2010 21:38, Kyle Girard wrote:
Hello,
I am playing around with a plug-in for gcc but recently ran into the
road block that plug-ins aren't supported on Windows. Are there any
plans to add support for the windows platform in the future? If not,
what are the issues with supporting
On 06/30/2010 03:46 PM, Dave Korn wrote:
Although we could build plugins as Windows DLLs and have GCC load them at
runtime, if those DLLs needed to refer to anything in the main GCC executable,
it would have to be specifically linked to import it - and imports on Windows
have to explicitly
On 06/30/2010 03:46 PM, Dave Korn wrote:
Although we could build plugins as Windows DLLs and have GCC load them at
runtime, if those DLLs needed to refer to anything in the main GCC
executable,
it would have to be specifically linked to import it - and imports on
Windows
have to
25 matches
Mail list logo
