roxen.lists.pike.general

Subject Author Date
Re: c modules H. William Welliver III <hww3[at]riverweb[dot]com> 28-08-2009
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.