Re: guile 2.0.9 build on mingw

[ludo@gnu.org (Ludovic Courtès)]

Eli Zaretskii <eliz@gnu.org> skribis:

>> 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?

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’.