Re: Guile with win32 cross compiling

e thing to do anyway? Shouldn't we try to fix the configure.ac to make it more portable and to make it properly detect those MinGW things in the first place? Greets, Volker -- Volker Grabsch ---<<(())>>---

Re: Guile with win32 cross compiling

--- I ran builds builds from a clean Git checkout of commit "19761af161942ef18aa2b7891cbf718fc5be5945" of the stable-2.0 branch. Note that I would of course prefer a thread-supporting build of Guile, but the problem is that "libgc" refuses to build under MinGW with Pthreads, so I had to build libgc with "--enable-threads=win32". On the other hand, it seems that Guile assumes "libgc" to be built with "--enable-threads=pthreads". I'm not sure whether this should be fixed in libgc or in Guile. Nevertheless, this only accounts for half of the issues, as Guile also fails to build without threading suppport (--without-threads). As a final note, I'm using the "Pthreads-w32" library to provide pthread support under MinGW. (http://sourceware.org/pthreads-win32/) Greets, Volker -- Volker Grabsch ---<<(())>>---

Re: Guile with win32 cross compiling

Andy Wingo schrieb: > On Sat 23 Apr 2011 18:10, Volker Grabsch writes: > > > Andy Wingo schrieb: > >> Hmmm. Well. We have other code generators in Guile's build system; > >> notably the configure script (via config.h and other output files). > >>

Re: Guile with win32 cross compiling

Hello Andy, Andy Wingo schrieb: > On Fri 01 Apr 2011 20:50, Volker Grabsch writes: > > > "Portability fixes for win32 cross compiling" > > http://www.mail-archive.com/guile-devel@gnu.org/msg05308.html > > Ah yes. Thanks for that link. And t

Re: Guile with win32 cross compiling

compiling will only work well if the library versions of the build toolchain and the host toolchain don't differ too much. Is this really the way this is meant to be done? Please don't take this is as a harsh criticism. I just want to make sure that I fully understand this advice. Greets, Volker -- Volker Grabsch ---<<(())>>---

Re: Guile with win32 cross compiling

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

Guile with win32 cross compiling

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? Greets, Volker [1] http://mingw-cross-env.nongnu.org/ -- Volker Grabsch ---<<(())>>--- This file

Guile with win32 cross compiling

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? Greets, Volker [1] http://mingw-cross-env.nongnu.org/ -- Volker Grabsch ---<<(())>>---

Re: Portability fixes for win32 cross compiling

Ludovic Courtès schrieb: > Volker Grabsch writes: > > > The "gen-scmconfig" script includes a mix of native and > > cross headers, which goes horribly wrong when performing > > win32 cross compiling. > > What happens exactly? I don't think that the

Re: Portability fixes for win32 cross compiling

Mike Gran schrieb: > From: Volker Grabsch v...@notjusthosting.com > > Is it really necessary to #include the > > "uniconv.h" from the cross system and to provide corresponding > > SCM_ICONVEH_* constants? > > Probably not.  I doubt that the libunistring con

Portability fixes for win32 cross compiling

not sure about that. Maybe this feature is so common that one should assume "works=yes" when cross-compiling. Greets, Volker -- Volker Grabsch ---<<(())>>--- Administrator NotJustHosting GbR >From 6a05429f8da76475b7fc03ad42d308b98f6b777b Mon Sep 17 00:00:00 2001 From