R: Plugin development under windows

Davide Piombo Davide.Piombo@phase.eu
Mon Mar 27 16:04:00 GMT 2017


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



More information about the Gcc mailing list