[plt-scheme] MzScheme 207 and Cygwin 1.5.10(0.116/4/2)

From: Jordan Henderson (jordan.henderson at earthlink.net)
Date: Tue Jun 15 12:41:29 EDT 2004

Progress report:

It was surprisingly easy to build mzscheme under Cygwin with unixy options in 
sconfig.h (including uconfig.h, for example).  I kept USE_MZ_CYGWIN_SETJMP 
and USE_CYGWIN_IOB and I had a problem with timezone in seconds_to_date 
in fun.c which I solved by defining USE_TOD_FOR_TIMEZONE (no other 
configurations use this?).

A few oddities turned up in the setup (4a) step, like ~/plt/bin wasn't there, but 
I created this manually and setup almost completed.  srfi/4 depends on mzdyn 
which is dll based and I've still got that torn out, but everything else seemed to 
build and the web-server runs, as an example.

Next would be figuring out why I have the problems building with dlls.

If anybody wants to try this out, I could provide the diffs from 207, they are pretty 
minor so far.  

Should I be working against the CVS?  Is anyone else working on similar areas?

-----Original Message-----
From: Jordan Henderson <jordan.henderson at earthlink.net>
Sent: Jun 15, 2004 9:33 AM
To: plt-scheme at list.cs.brown.edu
Subject: [plt-scheme] MzScheme 207 and Cygwin 1.5.10(0.116/4/2)

  For list-related administrative tasks:
  http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Hello,

Anyone built MzScheme under a very recent Cygwin?  

I've tried, but I've hit problems.  

Here's a few observations:

- ./configure --enable-shared
   Won't build.  Complaint from libtool when attempting to compile mzstart.
   Dropped back to try without --enable-shared

- ./configure (without --enable-shared)
   Seems to have a problem with dll symbol redefinition.  Just as a test, I tore out
   the DLL stuff by not defining WINDOWS_DYNAMIC_LOAD in sconfig.h if __CYGWIN32__
   was set.  Also changed some makefiles.  This built, but it then bombed on the
   'mzscheme.exe -mvqM- setup' (step 4a in src/README).  It seems that the 
   resulting mzscheme thinks the load path should be C:\Documents and Settings\...
   rather than the cygwin-mapped directory hierarchies.

 From investigating sconfig.h and other files, it appears that cygwin is a hybrid build
to say the least.  It builds with a lot of Windows defines and uses Windows-like paths.
I'm thinking of trying to rework the build to make cygwin more of a Unix flavored build.

A lot of progress has been made in Cygwin to providing a fuller emulation
of a Unix environment and perhaps it could be made to work.  Possibly
the problems building MrEd under Cygwin could be addressed also.  

I would think that if the goal is to have a separate compiler chain supported for
extensions in a more "traditional" Windows32 environment, that this could be a
Mingw32 build (http://www.mingw.org/).

I thought before I tore off in my own direction, I would seek this list's advice on
such a plan.  If a more Unix-like build of the tools could be supported under Cygwin,
would there be much chance of this being incorporated into the main distribution or
is there a lot of attachment to just using gcc as a separate compiler option for 
integrating with the Windows environment.  I'm not saying that integration with the
Windows environment would be impossible if such a direction were taken, but it might
risk this.  I couldn't guarantee, of course, that such projects would work in the 
not-yet-implemented mingw32 branch or even that such a hypothetical build would
even be done by me as I'm more interested in the Cygwin-only build.

I would suggest that there's less reason to support gcc as a compiler option now that
you can get the CLI version of the Microsoft C compiler (I'd provide a URL for this, but
I can't seem to reach microsoft.com right now to verify my bookmark), but I could see 
where people might have grown dependent on gcc for their projects.

I'm just looking for advice here, not some definite commitment of direction.  I wouldn't 
expect a commitment based on just a statement of direction.

Thanks.

-Jordan Henderson







Posted on the users mailing list.