> "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 > ---<<(())>>---
