Re:Reconsideration of MinGW work

[carlo\.bramix]

Hello,
I just wanted to report that I built GUILE 1.9.9 successfully on cygwin.

Some remarks:
1- I could not find libunistring, libffi and libgc into cygwin repository, so 
you will need to build these libraries yourself too. Let's hope they will be 
included too one day...
2- I received a strange warning message when doing configure: it said that my 
libreadline was too old and I had to upgrade to version 2.1. I compiled GUILE 
anyways and it was able to complete the process. I do not know if this will be 
cause of troubles or not.

BTW, if somebody of you is trying to use mingw, do not use latest binutils 
2.20.x. It really seems to me there are some troubles when exporting symbols 
when linking shared libraries. If you encounter some problems or you want to be 
more sure,  continue to use binutils 2.19.x. I did this downgrade and it solved 
my troubles.

Sincerely,

Carlo Bramini.


> I've been making gradual progress on MinGW cross building, but I've
> reached a point where I'm no longer sure that this is worthwhile.  This
> email explains why, and invites comments from anyone interested in this
> - especially from anyone who is really trying to use Guile on Windows.
>
> 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.
>
> Therefore the definition of "success" also needs to include a successful
> "make check", or some equivalent of that.  Using MSYS and MinGW on
> Windows, I assume that "make check" can be run just as easily as
> "make".  When cross-building with i586-mingw32msvc-* tools on Linux,
> "make check" can be run (in principle) if you also have Wine installed,
> and that's the setup that I've been using recently.
>
> 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.
>
> 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.
>
> 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.
>
> 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
>
> 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.
>
> - As far as 1.8.x is concerned, I'm not sure if there's any need out
>   there that isn't already met either by Cygwin or by the MinGW port
>   linked above.
>
> Anyone still reading?  Congratulations if so - and please let me know
> what you think!
>
> Regards,
>       Neil
>
>
>