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: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
