Re: Guile with win32 cross compiling

[Volker Grabsch <vog@notjusthosting.com>]

Andy Wingo schrieb:
> On Sat 26 Mar 2011 23:06, Volker Grabsch <vog@notjusthosting.com> writes:
> 
> > The first issue is the "#include <uniconv.h>" 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 <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.

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