[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile with win32 cross compiling

From: Mike Gran
Subject: Re: Guile with win32 cross compiling
Date: Tue, 5 Apr 2011 12:43:44 -0700 (PDT)

>     "Portability fixes for win32 cross compiling"
> > In any case, I don't understand the mechanism here, but I believe the
> > point was to make it so that #include <libguile.h> 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 <uniconv.h> 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 <stdio.h>
> 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.

There was a recent discussion about these sorts of builds at
> > > 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:
> > >
> > >
> > >
> > >
> > > 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
> ---<<(())>>---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]