[plt-scheme] MzScheme 207 and Cygwin 1.5.10(0.116/4/2)
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