[Mono-list] Latest mono for Cygwin

[Dan Lewis]

    --- Rogelio Robles <rogelio_robles@yahoo.com> wrote: > 
> Here is my own experience and the conclusions that I
> arrived.

Thanks Rogelio! That helped me a *lot* with the build on Linux, where for one
thing I was completely forgetting to transfer the class libraries across.

I also had some success with compiling Mono on Windows, in so far as getting
the
mint interpreter running hello world (with a few complaints). It needed a bit
of
hacking though - I get the feeling that mono once did run on Windows, but
development has gone on at a fast pace under Linux, and now the two are
slightly
out of sync. Now the following may all be complete rubbish (Mono developers
feel
free to interject and tell me so!), but for anyone who's interested here are my
thoughts:

At the moment the build system appears to have two Win32 targets, denoted by
the
defines PLATFORM_WIN32 and PLATFORM_WIN32_NATIVE. The first is meant for Cygwin
(Unix-style API, linking to the cywin1.dll emulation layer), the second for
MinGW. In case anyone is unfamiliar with MinGW, it's a set of include files
that
allow you to compile programs using gcc and link with Microsoft's own DLLs.
Kind
of like a free alternative to Visual C++, without the visuals. To compile
hello.c for MinGW, using the Cygwin toolchain, you run:

  gcc -mno-cygwin hello.c

(This tells gcc to use the include files in /usr/include/mingw and
/usr/include/w32api, and to link with MSVCRT.DLL instead of cygwin1.dll - that
is if you've installed the mingw runtime)

Now IMHO, I think the PLATFORM_WIN32 target (Cygwin) should be scrapped, or at
least put on the back burner - and PLATFORM_WIN32_NATIVE (MinGW) should be the
Windows default. The reason being is that Dick Porter's io-layer, which is sort
of like a mini-Cygwin in reverse, would be mapping the Windows API to the Unix
API, and then Cygwin would be mapping the Unix API back to Windows. This is
crazy enough, but you'd also have to actively maintain the code for Cygwin,
which is already missing a few screws. (Unfortunately it's difficult to use
both
cygwin1.dll and the MS runtime libraries together, because certain things
collide
- eg the sockets namespace).

To fully support the native target, we need to do a few things. Where Unix
libraries are used, a Windows alternative needs to be provided. There's an
example of this in rawbuffer.c, which uses mmap() under Unix and file mapping
under Windows. Thankfully there are only a few places where this needs to be
done (the class globber in monowrapper uses the Unix regex library, for
instance).

Secondly, a Windows target for corlib needs to be built. There's some code to
do
this in the class library, but I can't seem to get it to compile. (I could run
hello world using the Linux library, but the loader throws up loads of warnings
when it trys to link internal methods to libc and libm instead of MSVCRT.)

So what do you think? I know that a stable Linux target is the immediate goal,
but it would be nice to be able to run Mono and MS.NET side-by-side when
developing, for verification purposes.

Dan.


__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com