> Brian Dessent :
[snip! Access from plugins to every aspect of the compiler]
> ... This means you'd have to move essentially everything into this
> mega-DLL, leaving cc1 and friends as merely stubs that set a flag and
> then call into the DLL never to return, since anything left in cc1
> woul
> To get around this you'd have to either
> link a separate copy of the plugin for each executable, or access the
> symbols in the executable indirectly through GetProcAddress and function
> pointers.
Hacking the compiler (or postlinker!) to emit a special constructor that
does the necessary GetPr
On Fri, 14 Nov 2008, Brian Dessent wrote:
> "Joseph S. Myers" wrote:
>
> > As I understand it, there is an alternative - put all the shared code in a
> > DLL on Windows if configuring with plugins enabled, and link both the
> > plugins and cc1, cc1plus etc. with that DLL. If people wish to enabl
"Joseph S. Myers" wrote:
> As I understand it, there is an alternative - put all the shared code in a
> DLL on Windows if configuring with plugins enabled, and link both the
> plugins and cc1, cc1plus etc. with that DLL. If people wish to enable
The problem with that approach is that people have
On Fri, 14 Nov 2008, Brian Dessent wrote:
> Andrew Haley wrote:
>
> > So do that, then. Where's the problem?
>
> I suppose it's not a problem if the alternative is no plugin support at
> all. It just seems a little ugly for the plugin author to have to
> distribute 'n' trivially different but
Andrew Haley wrote:
> So do that, then. Where's the problem?
I suppose it's not a problem if the alternative is no plugin support at
all. It just seems a little ugly for the plugin author to have to
distribute 'n' trivially different but substantially identical copies of
their plugin binary for
Tim Prince wrote:
> bootstrap failures are due to a broken #ifdef specific to cygwin in the
> headers provided with cygwin,
If you mean the strsignal change in libiberty, that's been fixed in CVS
for a long time.
> the requirement for a specific version of
> autoconf (not available in setup),
Y
Brian Dessent wrote:
> Paul Brook wrote:
>
>> If you really want to solve this then you could always stop using PE/COFF.
>> The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates
>> how this can be done. Basically the toolchain generates ELF objects,
>> executables and DSOs,
Paul Brook wrote:
> If you really want to solve this then you could always stop using PE/COFF.
> The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates
> how this can be done. Basically the toolchain generates ELF objects,
> executables and DSOs, then you feed them through a
Brian Dessent wrote:
> Cygwin has been a secondary target for a number of years. MinGW has
> been a secondary target since 4.3. This generally means that they
> should be in fairly good shape, more or less. To quote the docs:
>
>> Our release criteria for the secondary platforms is:
>>
>>
On 14/11/2008, Brian Dessent <[EMAIL PROTECTED]> wrote:
> Andy Scott wrote:
>
> > Looking over the bugzilla data base and archives of this (and other)
> > lists I was wondering about the level of support there is for GCC on
> > Cygwin. (I realise that it is weird half-way house to many people an
> The real heart of the matter though is that most of the people that
> contribute to gcc aren't themselves users of these targets, and so it's
> only natural that they don't know about or care about the status of any
> target-specific issues. What has worried me lately however is how much
> ELF-s
Andy Scott wrote:
> Looking over the bugzilla data base and archives of this (and other)
> lists I was wondering about the level of support there is for GCC on
> Cygwin. (I realise that it is weird half-way house to many people and
> so does get a fair amount of "abuse" from both the Windoze &
> L
13 matches
Mail list logo
