This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: R: R: Plugin development under windows
On Tue, Mar 28, 2017 at 07:51:47AM +0000, Davide Piombo wrote:
> Hi Joseph,
> OK, thanks, now it clear to me your point.
> I do not know what the GCC plugin code really contains and I trust you when you say that GCC plugin section is not ready to handle dll on windows.
> But I still have two points that are not clear to me:
>
> 1- I found some historical references about the fact that exists a porting of dragonegg GCC plugin to Windows (dated 2011 running on GCC 4.6.1) that, following the description provided, has been obtained simply changing some parts of the GCC configure script. I tried to follow the instructions reported updating the configure script but without success.
> Does the problem is a different implementation of GCC plugin handling code in actual version?
> You can find the references of the dragonegg porting here:
> https://groups.google.com/forum/#!topic/llvm-dev/5631KDs-ETc
>
> 2- It is my opinion that there are some other problems than the dll handling. What I found trying to rebuild the plugin on windows is that the plugin doesn't build at all, and that the errors are not related to dll handling features.
> This drives me to think that in order to build a plugin where Windows is the Host for a GCC build it is necessary to do some other changes.
> What do you think about that?
>From your errors about posix headers, and since gcc also uses those I
suspect your mingw enviroment is not setup correctly.
Trev
>
> Thanks in advance
> Davide
>
>
> > -----Messaggio originale-----
> > Da: Joseph Myers [mailto:joseph@codesourcery.com]
> > Inviato: lunedì 27 marzo 2017 18:56
> > A: Davide Piombo
> > Cc: David Malcolm; 'gcc@gcc.gnu.org'
> > Oggetto: Re: R: Plugin development under windows
> >
> > On Mon, 27 Mar 2017, Davide Piombo wrote:
> >
> > > Sorry but it is not clear to me if the point is that the plugin
> > > development must include some windows-related code that I'm actually
> > > missing or if the problem is on the GCC side, that is inside GCC the
> > > code section that loads the dll, or part of it, is missing and it is
> > > still to be implemented.
> >
> > GCC only knows about how to dynamically load ELF shared libraries on a
> > Unix-like operating system. It does not know anything about whatever
> > interfaces Windows provides to load DLLs.
> >
> > GCC assumes a shared library can access symbols dynamically exported by
> > its internal cc1 and cc1plus executables. I've heard that DLLs work
> > differently (without an equivalent of -rdynamic), such that for a DLL
> > to access GCC-internal functions the whole of cc1/cc1plus would instead
> > need to be moved into a DLL.
> >
> > This requires someone with expertise on the relevant Windows facilities
> > (and probably significant cross-platform expertise as well, since you
> > need to adapt the build system and plugin support to do the required
> > things for each platform) to implement the support in GCC for plugins
> > on Windows host.
> >
> > --
> > Joseph S. Myers
> > joseph@codesourcery.com