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

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