This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
R: Plugin development under windows
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