I've not compiled pike on windows since 7.6, so my findings may be out of date. Mingw+gcc didn't produce a pike that could load modules dynamically, which basically meant it was impossible to develop your own dynamically loadable modules. Also, if that were fixed, I seem to recall there being a problem with linker incompatibility such that you couldn't load code compiled using the gnu toolchain with a a pike compiled using the ms toolchain.

I almost had an external module (my libxml2 parser)working using the ms toolchain with the current build system, but wasn't able to get all of the dependencies to compile and or link using microsoft's tools.

I can't see any reason why you couldn't use mingw to run the ms tools; it's just not the way things have been conventionally done.

Bill

On Tue, 25 Aug 2009, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:

People have had some limited success with MinGW, and it's getting better all the time so I think that's the way to go for windows compilation. It "just" needs to sort out the remaining quirks and odds and ends, if I'm not mistaken. Personally I don't have any experience of that, though.

The old method is admittedly exceedingly complex (and slow too). It has its roots in another era.. Once MinGW proves reliable it'll probably replace sprshd as the normal way of compilation, but unless MinGW can use the MS compiler, or at least the MS runtime lib, it'll probably stay around.

If you have the time and will, you're more than welcome to give it a shot with MinGW. It'd be very appreciated.