can anyone enlighten me as to the feasibility of compiling modules for windows outside of the install tree? is the build process still using two machines, or has that been worked out? i'm working on a number of projcts that might open pike up to new users, but not being able to compile modules on windows is becoming a roadblock on that platform.
any thoughts?
bill
ok, well, let's take it a step further, then...
since a given module can now be compiled in the pike tree or outside of it, does it stand to reason that there would be a way to make that happen on the windows platform, even if it involved the remote shell magic?
that said, can anyone describe the steps involved in setting up my own windows compile environment? did the work to use mingw get anywhere? i'm willing to dig into this (maybe even try to make it better), but there's not really enough info to go on for me to know where to start.
i vaguely remember that there was a requirement for a windows box and a unix box that shared a common filesystem. i also seem to remember that there was some sort of remote exec tool that had to run on the windows box. beyond that, i'm not sure what else needs to be in place...
any suggestions?
bill
On Thu, 22 Sep 2005, Peter Bortas @ Pike developers forum wrote:
It's never been done.
Nowdays it should be possible to compile native win32 binaries using Mingw. Using that suite, may also allow you to compile modules outside of the source tree. I havn't tried it, but it may be worth testing...
It is possible to compile Pike 7.7 on a windows machine with mingw. I even made a mingw-installer with everything you need in it, although it was quite a while ago. I'm not able to locate it now, but I can do it for you in a week when I return home.
I installed mingw and msys last night and started to compile Pike. The configuration process went ok ( i think, it was slow and I lost interest watching). It bombed on nettle, though. The compiler complained about .type and .size pseudo-codes being present outside of their .def block. there were 4 or 5 files like that, such as aes-decrypt.asm. I'm not sure what to do about that, as I'm not really an assembler kind of guy. I'd be willing to hear suggestions, though.
bill
On Fri, 23 Sep 2005, Martin Nilsson (lvl 60) @ Pike (-) developers forum wrote:
It is possible to compile Pike 7.7 on a windows machine with mingw. I even made a mingw-installer with everything you need in it, although it was quite a while ago. I'm not able to locate it now, but I can do it for you in a week when I return home.
That was my next step. It appears that the x86 asm code in nettle won't compile with gnu as. I have a hard time believing that, but according to the as docs, it's true.
bill
On Fri, 23 Sep 2005, Peter Bortas @ Pike developers forum wrote:
Try compiling nettle without asm optimizations.
That doesn't sound right. As far as I know masm is not installed on any of the normal test machines. gas would normally be the only available assembler.
Sidenote: Trying to compile it with VS will fail. I've tried to cross-compile the nettle assembler code for win32-PE on Unix for the two-machine setup, but unfortunately the semi-experimental win32PE support in upstream gas does not deliver something that VS is completely happy with. The normal win32 builds use a hand-compiled nettle done by someone at Roxen.
My current understanding is that the assembler files use some pseudo-ops which work with ELF but not with COFF (the object format on windows), or at least not with gas on COFF.
I'd appreciate if someone with access to and knowledge of windows could figure out precisely what's wrong, and how to fix it.
Alternatives are
* Use some subset of pseudo-ops that works on both windows/coff and unix/elf.
* Use some m4-macros for generating the prologue and epilogue of assembler functions, and setup configure to do the right thing. See for exaxmple how ASM_SYMBOL_PREFIX is chosen by configure, and substituted into config.m4.
* Completely remove all pseudo-ops that only affect debugging information anyway. But it would be nice to keep sufficient information to be able to generate backtraces in gdb.
I'll admit that I don't fully understand what the pseudo-ops are supposed to do on ELF either.
Ok, I was able to successfully compile and install pike from mingw + msys.
Here are the steps:
compile gmp as usual:
./configure make make install
untar nettle-1.12.tar.gz untar nettle-1.12.ptar.gz
set env variables:
CFLAGS="-I/usr/local/include" LDFLAGS="-L/usr/local/lib" export CFLAGS LDFLAGS
compile nettle:
./configure --disable-assembler make make install
compile pike 7.7:
./configure make make install
This seems to work just fine, so now I need to look at modules. It's not clear to me whether the generated module.so files are compatible with the standard windows version of pike and vice versa, as the mingw version doesn't seem to have load_module().
Bill
Yes, nettle needed som tinkering. I added a compiled nettle in my mingw package, so it doesn`t have to be compiled.
could that compiled nettle be made available for download?
greetings, martin.
It is available, as I have stated. I can answer from where it is available when I get home (or you can search the archives for my messages where I detailed how to build with MingW).
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
Marcus Agehall (PacketFront) ＠ Pike (-) developers forum -
Martin Bähr -
Martin Nilsson (lvl 60) ＠ Pike (-) developers forum
-
Niels M�ller () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum