[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: guile 2.0.9 build on mingw

From: Ludovic Courtès
Subject: Re: guile 2.0.9 build on mingw
Date: Wed, 12 Jun 2013 00:11:46 +0200
User-agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux)

Eli Zaretskii <address@hidden> skribis:

>> From: Mark H Weaver <address@hidden>
>> Cc: address@hidden,  address@hidden
>> 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, 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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]