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: Sun, 21 Mar 2010 23:45:43 +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 1269211589 20335 80.91.229.12 (21 Mar 2010 22:46:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 21 Mar 2010 22:46:29 +0000 (UTC) To: "guile-devel" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Mar 21 23:46: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 1NtTu8-00088b-RY for guile-devel@m.gmane.org; Sun, 21 Mar 2010 23:45:57 +0100 Original-Received: from localhost ([127.0.0.1]:35609 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtTu8-0000n5-4j for guile-devel@m.gmane.org; Sun, 21 Mar 2010 18:45:56 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NtTu5-0000n0-G0 for guile-devel@gnu.org; Sun, 21 Mar 2010 18:45:53 -0400 Original-Received: from [140.186.70.92] (port=36509 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NtTu2-0000ms-Ie for guile-devel@gnu.org; Sun, 21 Mar 2010 18:45:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1NtTtz-0006Pe-NW for guile-devel@gnu.org; Sun, 21 Mar 2010 18:45:50 -0400 Original-Received: from cp-out1.libero.it ([212.52.84.101]:57701) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1NtTtz-0006PT-As for guile-devel@gnu.org; Sun, 21 Mar 2010 18:45:47 -0400 Original-Received: from libero.it (192.168.33.213) by cp-out1.libero.it (8.5.115) id 4AB234230A43BDB8 for guile-devel@gnu.org; Sun, 21 Mar 2010 23:45:43 +0100 X-Sensitivity: 3 X-XaM3-API-Version: 4.3 (R1) (B3pl25) X-SenderIP: 95.236.70.55 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:10063 Archived-At: 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 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. 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 l= ibraries at mingw downloads but, unfortunately, I was not able to make th= em 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=3Dblob;f=3Ddlls/msvcrt/process.c= ;h=3D0b1eb01d2728b4df9e7d12a457dd3065bed1f1d1;hb=3DHEAD As you can see, you get a SIGSEGV because the parameter "cmd" (which is N= ULL 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/_sys= tem.c?view=3Dmarkup > 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. I have not tried to compile latest GUILE 1.9.9 on CYGWIN but I will try i= t 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, 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. Cygwin is the easier and quickest way for getting a posix software workin= g 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 ut= ilities (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 cyg= win. 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 wan= ted to show you why true win32 applications should be prefered to the one= s 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. 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 > Me too, I made a working GUILE 1.8.6 that I'm currently using and until n= ow it worked fine; afterall, I'm trying to build GUILE on Windows since v= ersion 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 solu= tion. Sincerely, Carlo Bramini.