Re: Guile with win32 cross compiling

[Mike Gran <spk121@yahoo.com>]

>     "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 <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
http://lists.gnu.org/archive/html/automake/2011-04/msg00014.html
 
> 
> > > 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
> ---<<(())>>---