Vladimir Zhbanov <[email protected]> skribis: > On Tue, Oct 27, 2015 at 06:54:44PM +0100, Ludovic Courtès wrote: >> Rafik NACCACHE <[email protected]> skribis: >> >> > Is there any new release planned soon? >> >> We’ve been meaning to release 2.0.12, which is mostly bug fixes. > > The stable-2.0 guile branch contains changes that some of our users > (that is, users of gEDA/gaf) have been waiting for years, especially > after guile 2.0 became necessary to build our package. I mean those > users who have been waiting for Windows support. (Some of them insist on > moving to using Python instead of Guile these days, since they have been > tired trying to cross-compile with guile-2.0 support.) A while ago I was > eventually able to build our toolkit using only one patch for guile [1] > (almost one-liner, in essence), and several work-around patches for some > of our programs, which can be found at [2] and are actually the same > code blocks (declaring an array and doing its initialisation). I don't > know why the latter patches work (geda-gaf with guile 1.8 worked without > them), however, I am sure the issue is in guile 2.0, though I cannot > even found the culprit by bisecting (because of too many changes in both > guile and geda-gaf repositories). Having said all that, I'd like to see > at least the patch [1] committed before the next guile release in order > to have guile cross-compilation for windows working. Are there any > chances for that?
Sure, we’ll do our best. > [1] > https://github.com/vzh/minipack/blob/master/patches/guile/0001-MinGW-build-support.patch Could you explain the details? An excerpt of the build log when cross-compiling to MinGW without the patch would be great. The reason I ask is that we rely on Gnulib for these portability things. The <sys/select.h> in libguile/iselect.h is supposed to do the right thing; if it’s not, we should (1) update our Gnulib copy, and (2) fix the problem in Gnulib if it’s still there. Thanks, Ludo’.
