On November 28, 2006 5:17 AM Gaby wrote: > > I installed mingw on yet another machine, restarted everything > from scratch, and now I can report that I was able to build > GCL-2.6.8pre on mingw and preliminary tests I made were working. >
Great. I did not complete my testing of a new MSYS/MinGW configuration because I got bitten by another repository bug. I still can not use svn (TortioseSVN) on Windows because the SourceForge site dies with the well known read error and irrevocably locks the repository. And I can not obtain build-improvements from Google Code because we long ago exceeded the maximum allowed capacity of that site and it is no longer being updated. So I opted for darcs only to discover that at patch 150 the 'get' it dies because it says it cannot apply the rename of SEGBIND.ps. And I haven't figured out how to stop darcs from applying this patch. This is a new failure sense it used to work *before* we decided to normalize the duplicate file names to lower case. I wonder whether 'darcs get' of build-improvements still works on MAC OSX? Right now I am trying again using Mercurial. > However, I was unable to build a working gcl on cygwin using the > mingw package. The generated executable does not use cygwin dll, > but raw_pre_gcl generated a stack overflow (my mingw/cygwin-fu is > not adequate to tackle a debug yet). Consequently, the link for > saved_gcl with for unresolved symbols (which are present in > libgcl.a!). Adapting gcl memory management to windows is a big problem. Mike Thomas did most of the work to make gcl run on Windows but he specifically did not want to work with cygwin. I am not sure that Mike is still here on this email list... but with Camm's help we might be able to solve this problem for cygwin. > > Then I decided to try build-improvements on mingw to get a feeling. > That led to rethink some configure test. Pristine noweb cannot > be compiled on mingw because the archive contains symlinks. The MSYS tools (including tar, I think) simulate symlinks via copy. This works in most cases. In particular I am able to compile noweb without changes. > So untarred noweb using cygwin, modified the makefile using cygwin, > then invoked make [all install] under mingw. Usually mixing cygwin and MSYS/MinGW tools is a *bad* idea because they use quite different conventions when it comes to solving compatibility problems with Windows. > I had a functional noweb installed. > Next, the modified build-improvement's configure completed (under > mingw). Make stopped on bsdsignal.c. Which prompted me to look > into, and get out horrified: Axiom has a tendency of checking for > platforms, when in fact it is interested in functionalities most > of the time. I changed bsdsignal.c to test for availability of > sigaction(), SA_RESTART, SA_INTERRUPT, etc. The build proceeded > till func_key.c which has some calls to fork() and wait(). At > that point, I decided that I had enough experience for tonight > and tackle daytime job things. I am surprised that bsdsignal.c compiled. I think Windows has fewer and different signals than unix. There is no fork() or wait() under native Windows so that was a good place to suspend your testing. :-) > > I'll install a cross-compiling environment linux-x-mingw and > use that for further investigation. I suspect that you will find this even less likely to succeed but I am interested in seeing how far you get. > And I'll tackle the mingw/cygwin issue much later when time > permits. > I keep hoping that some day the Axiom project will attract a really experienced Windows Developer... Regards, Bill Page. _______________________________________________ Axiom-developer mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/axiom-developer
