bug-guile
[Top][All Lists]
Advanced

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

bug#14361: Building guile 2.0.9 under mingw + msys


From: Andy Wingo
Subject: bug#14361: Building guile 2.0.9 under mingw + msys
Date: Mon, 20 Jun 2016 23:19:24 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

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 <address@hidden> writes:

>> From: Andy Wingo <address@hidden>
>> Cc: address@hidden,  address@hidden
>> 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
>> address@hidden 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





reply via email to

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