Re: guile 2.0.9 build on mingw

[Eli Zaretskii <eliz@gnu.org>]

> From: Mark H Weaver <mhw@netris.org>
> Cc: ludo@gnu.org,  guile-user@gnu.org
> 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?

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.

Btw, --disable-posix disables too much, for no good reason.  E.g., it
removes such innocent and important functionalities as "chdir",
"open", and "close".  This is unnecessary, especially since most of
the functions disabled by --disable-posix already have HAVE_foo guards
around them, so systems that don't have them will not have the
corresponding Guile feature.  I will try to lift as much of the
disabled functionality as MinGW can bear.

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?

Thanks.