Eli Zaretskii <[email protected]> skribis: >> From: Mark H Weaver <[email protected]> >> Cc: [email protected], [email protected] >> Date: Mon, 10 Jun 2013 16:54:44 -0400 >> >> There are some remaining problems revealed by the test suite, but the >> two people I spoke to reported that Guile 2.0.9 mostly works on mingw, >> if configured with --disable-posix. >> >> >> Are you configuring Guile with --disable-posix? >> > >> > No. Should I? >> >> Yes. Ideally our configure script would --disable-posix by default on >> mingw, but for now it has to be specified manually. > > Thanks. I tried that, but it didn't help. I see the same problems as > without --disable-posix. > > What eventually did the trick was configuring --with-threads=no. Once > I did that, the build ran successfully and almost 100% cleanly to > completion. (I will report the details about "almost" later.) > > I will try to compare the two builds and find what breaks the one with > threads. Since my knowledge about pthreads in general and on Windows > in particular is strictly zero, I'm not sure I'll know where to look. > So perhaps the following observation will help someone here to come up > with ideas or hints about where to look: Guile gets stuck when it is > about to exit. That is, it processes its input completely (e.g., > compiles the .scm file), writes out the corresponding output (e.g., > the .go file), announces that the output was written, and then gets > stuck. So this suggests something related to some bookkeeping done at > exit; any ideas what that could be?
The backtrace you reported before suggests that it’s stuck waiting for a signal delivery thread mutex, right? I have no idea how this would happen, though. > If no ideas are brought up, I guess the conclusion is that Guile on > Windows cannot be built with pthreads, at least not with their binary > package distributed by mingw.org, which is what I used. [...] FWIW, Guile cross-builds fine to MinGW with pthread-w32 and pthread support, but that runs none of the C code since it uses the native Guile to compile the .scm files. > Another set of disabled features is the network related functions -- > for some reason, the build process insists on h_errno being available, > although h_errno is an obsolete facility that AFAIK no one is treating > seriously anymore. Why not use errno instead? I don’t know. It’s used only in net_db.c, and only if ‘h_errno’ is available. Is there any harm in using it when it’s available? Could it be that older-but-not-too-old MinGW versions required use of ‘h_errno’? Thanks, Ludo’.
