RE: [Axiom-developer] build-improvements on cygwin

[Bill Page]

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.