I'm going to inject myself into this conversation, as I think I've
come closest to doing what you want to do in the past.
In order to generate a module that will be binary compatible with the
distributed binary pike, you must use the microsoft compiler
toolchain. If you use gcc and friends, it won't work.
As you've noted, pike is compiled using a lot of gnu tools, like
autoconf and friends. That's because the windows version of pike is
built using a set of unix tool "lookalikes" that actually drive the
microsoft tools. For example, there's a script that "looks like" gcc
but really transforms the arguments and runs the microsoft c compiler.
Historically, this crazy process was run by a unix based computer
whose filesystem was shared with the windows box that will actually be
performing the build. A pike based "remote shell" is run on the
windows system that listens for the converted microsoft tool commands
to come from the unix machine that's running these "stub" commands.
I think what's been suggested is that you can run the variant of the
above that eliminates the unix machine and shared directory by running
the build process (using those special stub tool-converter scripts)
from mingw directly on the machine with the microsoft tool chain
installed.
It's a little hazy about how to do that, but I believe you need to
download the nt-tools project from CVS and put at the head of your
msys path. There are a bunch of environment variables you'll need to
set to tell the stub tools how to work (such as the mode you're using,
where directories are located, etc). Finally, you'll need to set your
CC environment variable to use the nt-tools compiler.
Also, I'd note that the makefile that marcus agehall provided doesn't
use the build system that the standard pike modules use. I'm not sure
if it's been tested at all under windows or not. Initially, it might
be better to use a standard pike stub module and build it using "pike -
x module". You can find one of those in my SVN repo:
http://wush.net/svn/hww3/trunk/pike_modules/SampleModule
.
I should note that this _can_ be made to work... it's a bit tricky
(not to mention a huge pain). I ran into problems when I started
trying to use libraries that just didn't mingle well with the rest of
windows.
Good luck!
Bill
On Aug 28, 2009, at 7:48 AM, Yvan Vander Sanden wrote:
>
>
> 2009/8/28 Martin Stjernholm <<mast[at]lysator.liu.se>>
> Yvan Vander Sanden <<yvan[at]youngmusic.org>> wrote:
>
> > But then, what is the right compiler to use? Because global.h
> seems to rely on
> > unistd.h, which is not compatible with the msvc compiler.
>
> It works because HAVE_UNISTD_H isn't defined when msvc is used.
> Apparently you have a machine.h that wasn't generated using msvc.
>
> Ah, ok. I am using the header files included with the windows
> binary. If these are wrong, how to get the right ones? Because if i
> read the comments in machine.h:
>
> /* machine.h. Generated from machine.h.in by configure. */
> /* machine.h.in. Generated from configure.in by autoheader. */
>
> i conclude that i cannot do this with msvc, since it does not
> support autoheader. It's why people suggested i should use
> MSYS/'MinGW. Which means i'm back were I started, being the
> conclusion that pike cannot be compiled by msvc because it depends
> on make & configure too heavily.
>
> Is there actually anyone who has compiled c modules for the windows
> library? Because i would really like to know which tools i have to
> use.
>
> --
> Copyright only exists in the imagination of those who do not have any.
|