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
On 6 July 2010 23:05, Grigori Fursin 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 personally would like
s.com
[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 wrote
On 6 July 2010 17:54, Grigori Fursin 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 that plug-in
>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 r
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 workin
> 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 b
Quoting Kyle Girard :
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 hacke
> 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 sysadmi
Joern Rennecke wrote:
[gcc plugins rely on ELF features and therefore don't work on MS windows]
Quoting David Brown :
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.
>
[gcc plugins rely on ELF features and therefore don't work on MS windows]
Quoting David Brown :
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 p
On Thu, Jul 1, 2010 at 3:23 PM, Joern Rennecke wrote:
> Quoting Richard Guenther :
>
>> 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 st
Quoting Richard Guenther :
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
cares about the plugin working
On Thu, Jul 1, 2010 at 2:48 PM, David Brown 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 it
> would be nice t
On 01/07/2010 12:14, Joern Rennecke wrote:
Quoting David Brown :
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 wo
On 1 July 2010 12:14, Joern Rennecke 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 using gcc
Quoting David Brown :
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.
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,
wh
> 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
>
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 explicitl
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 suppor
Quoting Kyle Girard :
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 to send the compile job
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 issu
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
25 matches
Mail list logo
