From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "carlo\.bramix" Newsgroups: gmane.lisp.guile.devel Subject: Re:Reconsideration of MinGW work Date: Mon, 22 Mar 2010 13:51:05 +0100 Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1269262295 29508 80.91.229.12 (22 Mar 2010 12:51:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 22 Mar 2010 12:51:35 +0000 (UTC) To: "guile-devel" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Mar 22 13:51:31 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 1Nth6P-0006dm-KS for guile-devel@m.gmane.org; Mon, 22 Mar 2010 13:51:31 +0100 Original-Received: from localhost ([127.0.0.1]:41815 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nth6K-0008NF-7t for guile-devel@m.gmane.org; Mon, 22 Mar 2010 08:51:24 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nth6D-0008Mx-GM for guile-devel@gnu.org; Mon, 22 Mar 2010 08:51:17 -0400 Original-Received: from [140.186.70.92] (port=44594 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nth6B-0008Mh-AH for guile-devel@gnu.org; Mon, 22 Mar 2010 08:51:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nth65-0006Q2-2k for guile-devel@gnu.org; Mon, 22 Mar 2010 08:51:14 -0400 Original-Received: from cp-out4.libero.it ([212.52.84.104]:59103) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nth64-0006Pd-GO for guile-devel@gnu.org; Mon, 22 Mar 2010 08:51:09 -0400 Original-Received: from libero.it (192.168.33.213) by cp-out4.libero.it (8.5.107) id 4BA25F08002BAF36 for guile-devel@gnu.org; Mon, 22 Mar 2010 13:51:05 +0100 X-Sensitivity: 3 X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 213.203.169.135 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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:10066 Archived-At: 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 tha= t my libreadline was too old and I had to upgrade to version 2.1. I compi= led 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 binutil= s 2.20.x. It really seems to me there are some troubles when exporting sy= mbols when linking shared libraries. If you encounter some problems or yo= u want to be more sure, continue to use binutils 2.19.x. I did this down= grade 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 piece= s > 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 b= e > 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 successfu= l > "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 muc= h > 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, an= d > the MinGW website is actually very clear about this. That means that i= t > 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 t= o > 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. An= d > 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 > > >