Re:Reconsideration of MinGW work

[carlo\.bramix]

Hello!

> First, I've found that completing a successful build (i.e. autogen.sh,
> configure and make) is not at all the end of the story; it's only the
> first part of what is really needed - because at runtime some key pieces
> of function can still be missing, or can behave differently on
> MinGW/Windows than on Linux/POSIX.  Two examples of this are operations
> on file descriptors - where on MinGW/Windows different functions must be
> called for sockets than for real files - and regular expressions, which
> are not supported by the MinGW/Windows C library.

Unfortunately, the network is one of the common problems when porting. It could 
be resoved with some work and with some "tricks" if someone wants.
Did you mean "regex" with "regular expressions"? There are two of these 
libraries at mingw downloads but, unfortunately, I was not able to make them 
working: I had to take original sources and I recompiled myself.

> Second, though, it turns out that using i586-mingw32msvc-* and Wine on
> Linux unfortunately does not give the same results as MSYS and MinGW on
> Windows.  For example I've found that system(NULL) throws a SIGSEGV
> under Wine, but for Carlo Bramix, working on Windows, that wasn't a
> problem; and instead, for Carlo, there were other problems that I don't
> see with a Linux cross build.

Yes, it seems to be a bug of WINE.
Look the sources of _wsystem() function at:

http://source.winehq.org/git/wine.git/?a=blob;f=dlls/msvcrt/process.c;h=0b1eb01d2728b4df9e7d12a457dd3065bed1f1d1;hb=HEAD

As you can see, you get a SIGSEGV because the parameter "cmd" (which is NULL in 
sources of GUILE) is used immediately in strlenW().
Hopefully, this bug does not exist in the sources of ReactOS:

http://svn.reactos.org/svn/reactos/trunk/reactos/lib/sdk/crt/process/_system.c?view=markup

> This is hardly surprising.  Although Wine aims to emulate the Windows
> runtime DLLs precisely, of course it is only software and so can have
> bugs.  But it is an extra hassle in practice.
>
> Third, I reviewed my own need for Guile on Windows - and in fact I've
> been perfectly happily using the Cygwin version for some time now.  So
> actually I don't currently need a MinGW version - and maybe that would
> be true for other Guile on Windows users too.
>
> Looking forwards, supporting a Cygwin build of Guile will always be much
> easier than supporting a MinGW build, because the whole point of Cygwin
> is to provide an emulation on Windows of the POSIX API, and that's what
> most of the Guile code assumes.

I have not tried to compile latest GUILE 1.9.9 on CYGWIN but I will try it in 
the lunch pause tomorrow.
I'm quite confident it will work because I had not particular problems on 
previous versions.

> Fourth, I've realized that I significantly misunderstood MinGW's
> objective.  Its true objective is to provide free software tools for
> building native Windows programs to run with the Win32 runtime DLLs, and
> the MinGW website is actually very clear about this.  That means that it
> is 100% targeting the API provided by the Win32 DLLs.  But somehow or
> other I had got the idea that it was also a bit Cygwin-ish, in trying to
> provide pieces of the Linux/POSIX API that aren't provided by those
> DLLs.
>
> That last idea is completely wrong, which means that trying to build a
> POSIX-assuming project for MinGW is always going to be hard.

Cygwin is the easier and quickest way for getting a posix software working on 
Windows, at least for a developer: configure, make, make install and it is done.
For an user, things may be a bit different and this is the reason because I 
started to port many free software and libraries to mingw with msys utilities 
(bash and typical unix tools).
Just for making an example, a simple graphical "Hello world!" application needs 
an absurd, huge amount of software, including a slave X server.
Instead, everything compiled with mingw is a plain win32 application that can 
run directly on the Windows Desktopand few DLLs, well integrated in the system 
and running at a native speed that you will never reach in cygwin.
Although many efforts have been made, cygwin acts more similar to virtual 
machine to me.
I'm not trying to change the decisions of the team in any way, I just wanted to 
show you why true win32 applications should be prefered to the ones made with 
cygwin (if this is possible to do, of course!).

> Fifth, and now thinking more of the future with 1.9/2.0, I wondered if
> it would be better to address MinGW porting problems within Gnulib,
> instead of putting lots of #ifdef __MINGW32__ into Guile's own code.
> And in fact yes, based on a small and completely unscientific sample of
> Google results, it seems the Gnulib guys do regard MinGW compatibility
> as part of their remit.
>
> So putting #ifdef __MINGW32__ stuff into Guile is probably unhelpful
> anyway, because it would be better to contribute to Gnulib instead.  And
> it's possible that Gnulib might already have what we need.
>
> And finally, I noticed that there already claims to be a MinGW port of
> Guile 1.8, here:
>
> http://sourceforge.net/projects/mingw/files/
> http://sourceforge.net/projects/mingw/files/MSYS%20guile/guile-1.8.7-1/guile-1.8.7-1-msys.RELEASE_NOTES/download
>

Me too, I made a working GUILE 1.8.6 that I'm currently using and until now it 
worked fine; afterall, I'm trying to build GUILE on Windows since version 1.8.3 
:P

> Therefore I'm inclined to conclude the following.
>
> - Overall, it isn't as important as I had been thinking to get a
>   complete MinGW build of Guile.  I personally plan to concentrate more
>   now on 1.8 - 1.9/2.0 compatibility, and on the manual.
>
> - As far as future development is concerned, including the current
>   "master" branch, MinGW portability fixes should be directed at Gnulib
>   if possible, instead of done directly in the Guile code.

For a project as complex as guile, probably this sounds to be a good solution.

Sincerely,

Carlo Bramini.