GNU bug report logs -
#14361
Building guile 2.0.9 under mingw + msys
Previous Next
Reported by: Eli Zaretskii <eliz <at> gnu.org>
Date: Tue, 7 May 2013 17:20:02 UTC
Severity: normal
Done: Andy Wingo <wingo <at> pobox.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your message dated Mon, 20 Jun 2016 23:19:24 +0200
with message-id <8737o77e3n.fsf <at> pobox.com>
and subject line Re: bug#14361: Building guile 2.0.9 under mingw + msys
has caused the debbugs.gnu.org bug report #14361,
regarding Building guile 2.0.9 under mingw + msys
to be marked as done.
(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)
--
14361: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14361
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
> From: Andy Wingo <wingo <at> pobox.com>
> Cc: ludo <at> gnu.org, 10474-done <at> debbugs.gnu.org
> Date: Sun, 24 Feb 2013 14:25:06 +0100
>
> So with these last commits, hopefully native MinGW builds are supported.
> Would you mind testing again? Please send a new mail to
> bug-guile <at> gnu.org to track any new failures.
Thanks, and sorry for a long delay.
I tried today building Guile 2.0.9. The C compilation went very
smoothly, with only a couple of warnings (one is the known iconv
prototype "issue", the other a variable that is set and not used).
However, once it got to compiling Scheme files, it repeatedly failed
after writing each .go file. Here are a few typical failures:
GEN guile-procedures.texi
Backtrace:
In unknown file:
?: 3 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
?: 2 [apply-smob/1 #<catch-closure 2e07050> quit #<unspecified>]
?: 1 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
?: 0 [apply-smob/1 #<catch-closure 3f7eea0>]
ERROR:
The program then sits at the ERROR: prompt, but does not accept any
input.
Seems that this comes from smob.c:
static SCM
scm_smob_trampoline (unsigned int nreq, unsigned int nopt,
unsigned int rest)
{
SCM trampoline;
if (SCM_UNLIKELY (rest > 1 || nreq + nopt + rest > 3))
scm_out_of_range ("make-smob", scm_from_uint (nreq + nopt + rest));
trampoline = SCM_SMOB_TRAMPOLINE (nreq, nopt, rest);
if (SCM_LIKELY (SCM_UNPACK (trampoline)))
return trampoline;
switch (nreq + nopt + rest)
{
/* The + 1 is for the smob itself. */
case 0:
trampoline = scm_c_make_gsubr ("apply-smob/0", nreq + 1, nopt, rest,
apply_0);
break;
case 1:
trampoline = scm_c_make_gsubr ("apply-smob/1", nreq + 1, nopt, rest,
apply_1);
But I have no idea what it means.
When this happens, guile.exe still runs (actually, there are 2 Guile
processes, one a child of the other), so it is impossible to delete
guile-procedures.texi, because one of these processes holds it open.
I needed to kill guile.exe (the child) to be able to try again.
I tried "make -k" to see how far I can advance. The next compilation
of ice-9/eval.scm then stops with the same error:
make[2]: Entering directory `/d/usr/eli/utils/guile-2.0.9/module'
GUILEC ice-9/eval.go
wrote `ice-9/eval.go'
Backtrace:
In unknown file:
?: 3 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
?: 2 [apply-smob/1 #<catch-closure 2b12100> quit #<unspecified>]
?: 1 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
?: 0 [apply-smob/1 #<catch-closure 3af6340>]
ERROR:
Similarly after compiling ice-9/readline.scm:
wrote `ice-9/readline.go'
Backtrace:
In unknown file:
?: 4 [apply-smob/1 #<catch-closure 246faf0> quit #<unspecified>]
In ice-9/eval.scm:
484: 3 [eval # #]
481: 2 [lp (#<fluid 13>) (#<procedure 40d9d20 at ice-9/eval.scm:264:7 %args>)]
In unknown file:
?: 1 [apply-smob/1 #<catch-closure 3ccb440>]
In ice-9/eval.scm:
481: 0 [lp (#<fluid 12>) ((#<catch-closure 3ccb420>))]
ice-9/eval.scm:481:19:
Any ideas? Where should I look for the source of this problem?
TIA
[Message part 3 (message/rfc822, inline)]
Hi Eli :)
Thank you for your ongoing work on MinGW and Guile, it's really
appreciated. I just wanted to say that explicitly here, even though I'm
closing this bug, as I understand that things have progressed a bit in
these 3 years; anyway. Your work is so valuable to many users. Thanks!
Andy
On Tue 07 May 2013 19:18, Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Andy Wingo <wingo <at> pobox.com>
>> Cc: ludo <at> gnu.org, 10474-done <at> debbugs.gnu.org
>> Date: Sun, 24 Feb 2013 14:25:06 +0100
>>
>> So with these last commits, hopefully native MinGW builds are supported.
>> Would you mind testing again? Please send a new mail to
>> bug-guile <at> gnu.org to track any new failures.
>
> Thanks, and sorry for a long delay.
>
> I tried today building Guile 2.0.9. The C compilation went very
> smoothly, with only a couple of warnings (one is the known iconv
> prototype "issue", the other a variable that is set and not used).
> However, once it got to compiling Scheme files, it repeatedly failed
> after writing each .go file. Here are a few typical failures:
>
> GEN guile-procedures.texi
> Backtrace:
> In unknown file:
> ?: 3 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
> ?: 2 [apply-smob/1 #<catch-closure 2e07050> quit #<unspecified>]
> ?: 1 [apply-smob/1 #<boot-closure 234da60 (_ _ _)> #t ...]
> ?: 0 [apply-smob/1 #<catch-closure 3f7eea0>]
>
> ERROR:
>
> The program then sits at the ERROR: prompt, but does not accept any
> input.
>
> Seems that this comes from smob.c:
>
> static SCM
> scm_smob_trampoline (unsigned int nreq, unsigned int nopt,
> unsigned int rest)
> {
> SCM trampoline;
>
> if (SCM_UNLIKELY (rest > 1 || nreq + nopt + rest > 3))
> scm_out_of_range ("make-smob", scm_from_uint (nreq + nopt + rest));
>
> trampoline = SCM_SMOB_TRAMPOLINE (nreq, nopt, rest);
>
> if (SCM_LIKELY (SCM_UNPACK (trampoline)))
> return trampoline;
>
> switch (nreq + nopt + rest)
> {
> /* The + 1 is for the smob itself. */
> case 0:
> trampoline = scm_c_make_gsubr ("apply-smob/0", nreq + 1, nopt, rest,
> apply_0);
> break;
> case 1:
> trampoline = scm_c_make_gsubr ("apply-smob/1", nreq + 1, nopt, rest,
> apply_1);
>
> But I have no idea what it means.
>
> When this happens, guile.exe still runs (actually, there are 2 Guile
> processes, one a child of the other), so it is impossible to delete
> guile-procedures.texi, because one of these processes holds it open.
> I needed to kill guile.exe (the child) to be able to try again.
>
> I tried "make -k" to see how far I can advance. The next compilation
> of ice-9/eval.scm then stops with the same error:
>
> make[2]: Entering directory `/d/usr/eli/utils/guile-2.0.9/module'
> GUILEC ice-9/eval.go
> wrote `ice-9/eval.go'
> Backtrace:
> In unknown file:
> ?: 3 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
> ?: 2 [apply-smob/1 #<catch-closure 2b12100> quit #<unspecified>]
> ?: 1 [apply-smob/1 #<boot-closure 26cca60 (_ _ _)> #t ...]
> ?: 0 [apply-smob/1 #<catch-closure 3af6340>]
>
> ERROR:
>
> Similarly after compiling ice-9/readline.scm:
>
> wrote `ice-9/readline.go'
> Backtrace:
> In unknown file:
> ?: 4 [apply-smob/1 #<catch-closure 246faf0> quit #<unspecified>]
> In ice-9/eval.scm:
> 484: 3 [eval # #]
> 481: 2 [lp (#<fluid 13>) (#<procedure 40d9d20 at ice-9/eval.scm:264:7 %args>)]
> In unknown file:
> ?: 1 [apply-smob/1 #<catch-closure 3ccb440>]
> In ice-9/eval.scm:
> 481: 0 [lp (#<fluid 12>) ((#<catch-closure 3ccb420>))]
>
> ice-9/eval.scm:481:19:
>
> Any ideas? Where should I look for the source of this problem?
>
> TIA
This bug report was last modified 9 years and 53 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.