Hi Dave, thanks a lot for your ready answer.
> > The final platform target of the plugin is (unfortunately ;-)) > Windows > > and = I tried to rebuild the plugin using MinGW compiler (both with > > the Linux ver= sion as well by using MSYS2 and win-builds MinGW > > compilers for windows) but= the lack of POSIX includes breaks the > > build. > > (FWIW I've worked a lot with gcc plugins, but not on Windows). OK, in this case you are THE EXPERT... ;-) > > Sorry if I'm being obtuse here, but you say "the final platform target > of the plugin is...Windows" - does that mean that > - the compiler (and thus the plugin within it) are going to run on > Windows, and generate code for some (other?) system or that > - the compiler+plugin are going to run on some (other?) system, and > generate code intended to run on Windows? > > (AIUI the former case would mean that Windows is the *host*, the latter > that it's the *target*). Really sorry, my fault. First of all I had to clearly explain which is the environment... The final application will be host on windows and will have an ARM M4 as target. I'm working on the cross-compiler gcc-arm-none-eabi-6-2017-q1-update that I found on this site: https://launchpad.net/gcc-arm-embedded In the windows version of the toolchain the gcc plugin includes were deleted, I fixed this point but this didn't solve. As you can see I also asked about the compilation of gcc-plugin there but my question is still pending... As I already told you I successfully built the Linux version of the plugin, and then I tried the same build by using the MinGw cross compiler (on the same Linux Host). The MinGW version is the same used by the arm-embedded toolchain build script to generate the windows version of the toolchain. Using this configuration I tried to build the plugin, but the compilation failed as explained below. > > You say "the lack of POSIX includes breaks the build". > Can you give more specifics on what goes wrong? Maybe someone here can > figure out a good workaround/bugfix. Substantially I try to build the same plugin code that works on Linux using the MinGW compiler and the compiler stops with this error: /home/user/Projects/sources/gcc-arm-none-eabi-6-2017-q1-update/lib/gcc/arm-none-abi/6.3.1/plugin/include/system.h:396:22: fatal error: sys/wait.h: No such file or directory As first try I checked out the content of system.h file and I found that the include is in a pre-processor conditional block: #ifdef HAVE_SYS_WAIT_H #include <sys/wait.h> #endif And the same thing happens for other <sys/xxxx.h> include directives. I tried to force the behaviour of the build by manually change the auto-host.h file commenting out HAVE_SYS_WAIT_H and other pragmas in order to remove the dependencies from missing includes but after the exclusion on gmp.h in system.h the compilation goes very bad... > > I believe that compiler plugins needs to be built using the same build, > host and target configuration triplets as the compiler they're going to > be embedded in was built with. > Sorry, but this point is not really clear to me... Do you mean that I must use the same compiler used for the Linux plugin changing the build target from Linux to Windows and do not use the MinGW cross compiler? > > I looked around the documentation but I didn't find any reference > > regarding= the use of GCC plugins under windows. > > I only found some old posts on some forums saying that it is > possible > > to d= o that and that exist some old gcc versions (custom windows > > rebuild of GCC = > > 4.6.1 to use dragonegg as plugin) that can run plugins. > > > > Substantially I'm writing just to ask: > > Can GCC plugins run on a windows build of GCC compiler (MinGW) ? > > I suspect the answer is "you're the first person to try this in a > while; some things may need fixing" - but that's a guess :) > > > If it is possible to do that, which is the correct way to build the > > plugin? > > Good luck; I hope this is constructive. > Dave Thanks again for your help Davide
