This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Defining a common plugin machinery
- From: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>
- To: Brendon Costa <bcosta at avdat dot com dot au>
- Cc: Diego Novillo <dnovillo at google dot com>, gcc at gcc dot gnu dot org, Basile STARYNKEVITCH <basile at starynkevitch dot net>, Sean Callanan <spyffe at cs dot sunysb dot edu>
- Date: Fri, 19 Sep 2008 10:02:21 +0200
- Subject: Re: Defining a common plugin machinery
- References: <48CF93F7.8010901@google.com> <48D2F56B.7060708@avdat.com.au>
* Brendon Costa wrote on Fri, Sep 19, 2008 at 02:42:19AM CEST:
> What platforms do we want to support? I can think of the following
> categories:
> * Windows (cygwin/mingw)
> As i understand the issue (I am not very familiar with this) you can't
> have unresolved references in a plugin back to the GCC executable. I.e.
> Building GCC with -rdynamic will not work on this platform. Do we move
> most of the GCC implementation into a "library/DLL" having a "stub"
> main() that just calls the library implementation. Then both the
> application AND the plugins can link with this library/DLL in a way that
> will work on Windows.
> Or are we going for the quick solution of using -rdynamic and not
> supporting this platform (Not my preferred option)?
AFAIK you can fix w32 issues with DEF files.
I would guess putting the bulk of GCC in a library, thus compiling it
with PIC code on most systems, will hurt compiler performance rather
significantly. Haven't tried it though.
Cheers,
Ralf