Re:Reconsideration of MinGW work

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.

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
>
>
>