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? Thanks in advance Davide > -----Messaggio originale----- > Da: Joseph Myers [mailto:jos...@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 > jos...@codesourcery.com
