From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Volker Grabsch Newsgroups: gmane.lisp.guile.devel,gmane.lisp.guile.bugs Subject: Re: Guile with win32 cross compiling Date: Fri, 1 Apr 2011 20:50:20 +0200 Message-ID: <20110401185020.GC13643@flap> References: <20110326220651.GA8300@flap> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1301683865 14576 80.91.229.12 (1 Apr 2011 18:51:05 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2011 18:51:05 +0000 (UTC) Cc: bug-guile@gnu.org, guile-devel@gnu.org To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 01 20:50:58 2011 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 1Q5jQr-0001ts-1j for guile-devel@m.gmane.org; Fri, 01 Apr 2011 20:50:55 +0200 Original-Received: from localhost ([127.0.0.1]:43541 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5jQp-0006eS-4B for guile-devel@m.gmane.org; Fri, 01 Apr 2011 14:50:51 -0400 Original-Received: from [140.186.70.92] (port=60981 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q5jQV-0006Ty-Cl for guile-devel@gnu.org; Fri, 01 Apr 2011 14:50:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q5jQS-0002x5-HV for guile-devel@gnu.org; Fri, 01 Apr 2011 14:50:30 -0400 Original-Received: from mail.notjusthosting.com ([78.47.75.226]:35997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q5jQS-0002uO-CW; Fri, 01 Apr 2011 14:50:28 -0400 Original-Received: from p5df14b0c.dip.t-dialin.net ([93.241.75.12] helo=flap) by mail.notjusthosting.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1Q5jQL-0005UL-1K; Fri, 01 Apr 2011 18:50:21 +0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 78.47.75.226 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:12140 gmane.lisp.guile.bugs:5406 Archived-At: Andy Wingo schrieb: > On Sat 26 Mar 2011 23:06, Volker Grabsch writes: > > > The first issue is the "#include " in gen-scmconfig, > > which has already been discussed in the past and for which I > > already provided a clean, working solution. I forward-ported > > my patch to guile-2.0.0 and it seems to work. This patch is > > attached to this email, please consider applying it. > > I don't know what discussion you are referring to here; best to link. I'm referring to: "Portability fixes for win32 cross compiling" http://www.mail-archive.com/guile-devel@gnu.org/msg05308.html > In any case, I don't understand the mechanism here, but I believe the > point was to make it so that #include would not pull in > iconv headers. gen-scmconfig looks up the value of the constants for > iconv conversion handlers, and writes them into scmconfig.h. Your patch > undoes that. > > What problem are you working around here? The problem is that this mechanism works completely against the nature of cross compiling. The issue exists in all attempts to cross compile guile, but they become extreme when cross compiling on a Unix system for MinGW, as those systems are very different. Gen-scmconfig is a code generator, so it has to be built using the native toolchain. However, it is supposed to write take its values from the of the cross tool chain. Thus, the "/usr/include" equivalent of the cross tool chain is added to the include path when compiling gen-scmconfig. And here the trouble starts, because mixing headers of various toolchains is never a good idea. Among others, basic headers like are now taken from the cross toolchain, referring to objects that don't even exist in the native toolchain, causing the build to fail with all kinds of strange error messages. > > The other open issue is also a known one: the missing mmap() > > function under Windows. After some research, I found a promising > > mmap()/munmap() implementation for Windows in a free software > > project: > > > > http://code.google.com/p/flvmeta/source/browse/trunk/src/mmap.h?r=74 > > http://code.google.com/p/flvmeta/source/browse/trunk/src/mmap.c?r=74 > > > > Maybe this is worth integrating into guile? > > You know, not only do we not rely on MAP_SHARED -- I switched it to use > PRIVATE, just now -- we didn't actually need mmap at all. I just > changed it to use read(2) if mmap is not available, and it seems to work > fine, just a little (5-10%) slower to start up. That should help our > unfortunate friends working on Windows :) That's good news. Maybe this will enable me to include the next guile release in mingw-cross-env - a project dedicated to all those unfortunate friends. :-) Using mingw-cross-env and Wine, they at least don't have to actually run Windows just to build and test their project's Windows port. ;-) Greets, Volker -- Volker Grabsch ---<<(())>>---