From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.user Subject: Reconsideration of MinGW work Date: Sun, 21 Mar 2010 20:51:52 +0000 Message-ID: <87fx3tjt3r.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1269204753 31133 80.91.229.12 (21 Mar 2010 20:52:33 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 21 Mar 2010 20:52:33 +0000 (UTC) To: Guile Development , Guile User List Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Mar 21 21:52:24 2010 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1NtS8F-0000mz-W7 for guile-devel@m.gmane.org; Sun, 21 Mar 2010 21:52:24 +0100 Original-Received: from localhost ([127.0.0.1]:48447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtS8E-0001aE-EN for guile-devel@m.gmane.org; Sun, 21 Mar 2010 16:52:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtS88-0001Zf-WC for guile-devel@gnu.org; Sun, 21 Mar 2010 16:52:17 -0400 Original-Received: from [140.186.70.92] (port=49550 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtS86-0001ZM-Cl for guile-devel@gnu.org; Sun, 21 Mar 2010 16:52:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NtS83-0006NX-Ps for guile-devel@gnu.org; Sun, 21 Mar 2010 16:52:14 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:38130) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NtS83-0006NQ-EP; Sun, 21 Mar 2010 16:52:11 -0400 Original-Received: from arudy (host86-182-154-126.range86-182.btcentralplus.com [86.182.154.126]) by mail3.uklinux.net (Postfix) with ESMTP id 459EC1F6818; Sun, 21 Mar 2010 20:52:09 +0000 (GMT) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 1305B3801F; Sun, 21 Mar 2010 20:51:53 +0000 (GMT) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4-2.6 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:10061 gmane.lisp.guile.user:7692 Archived-At: 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