GNU bug report logs - #14361
Building guile 2.0.9 under mingw + msys

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14361 in the body.
You can then email your comments to 14361 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: bug-guile <at> gnu.org, ludo <at> gnu.org
Subject: Building guile 2.0.9 under mingw + msys
Date: Tue, 07 May 2013 20:18:05 +0300

> 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 #10 received at 14361-done <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14361-done <at> debbugs.gnu.org, ludo <at> gnu.org
Subject: Re: bug#14361: Building guile 2.0.9 under mingw + msys
Date: Mon, 20 Jun 2016 23:19:24 +0200

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

Message #13 received at 14361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 14361 <at> debbugs.gnu.org, ludo <at> gnu.org
Subject: Re: bug#14361: Building guile 2.0.9 under mingw + msys
Date: Tue, 21 Jun 2016 15:46:35 +0300

> From: Andy Wingo <wingo <at> pobox.com>
> Cc: 14361-done <at> debbugs.gnu.org,  ludo <at> gnu.org
> Date: Mon, 20 Jun 2016 23:19:24 +0200
> 
> 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!

Thanks.

I would be happier, though, if the patch for open-process, whose last
version I submitted here:

  https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00015.html

would be admitted to the repository, as it fixes important
functionality that is currently unavailable in the MinGW build with
upstream sources.  AFAIR, the last communication about this patch was
here:

  https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00024.html
  https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00041.html

I pinged about it a month later:

  https://lists.gnu.org/archive/html/guile-devel/2014-09/msg00066.html

but got no responses.

Message #16 received at 14361 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14361 <at> debbugs.gnu.org, ludo <at> gnu.org
Subject: Re: bug#14361: Building guile 2.0.9 under mingw + msys
Date: Tue, 21 Jun 2016 17:06:05 +0200

On Tue 21 Jun 2016 14:46, Eli Zaretskii <eliz <at> gnu.org> writes:

> I would be happier, though, if the patch for open-process, whose last
> version I submitted here:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00015.html
>
> would be admitted to the repository, as it fixes important
> functionality that is currently unavailable in the MinGW build with
> upstream sources.  AFAIR, the last communication about this patch was
> here:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00024.html
>   https://lists.gnu.org/archive/html/guile-devel/2014-08/msg00041.html
>
> I pinged about it a month later:
>
>   https://lists.gnu.org/archive/html/guile-devel/2014-09/msg00066.html
>
> but got no responses.

Let's give it a go!  I understand that you do not want to work with
gnulib.  That's a negative from a Guile POV -- but it's not a
deal-breaker.  The thing we like about Gnulib is that we like working
with POSIX abstractions as much as possible, and we find that it's
easier to do our work as Guile maintainers when we limit and reduce the
number of portability-related shims in our code.  To that end I hesitate
about including a bunch more stuff in posix.c.  Must it all be there, or
would it be possible to move some of it out to our own gnulib-like
mingw-w32.[ch] or something?

Andy

Message #19 received at 14361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 14361 <at> debbugs.gnu.org, ludo <at> gnu.org
Subject: Re: bug#14361: Building guile 2.0.9 under mingw + msys
Date: Tue, 21 Jun 2016 18:42:37 +0300

> From: Andy Wingo <wingo <at> pobox.com>
> Cc: 14361 <at> debbugs.gnu.org,  ludo <at> gnu.org
> Date: Tue, 21 Jun 2016 17:06:05 +0200
> 
> Let's give it a go!  I understand that you do not want to work with
> gnulib.  That's a negative from a Guile POV -- but it's not a
> deal-breaker.

I have nothing against Gnulib, but in this case their solution is
simply not up to speed.

> To that end I hesitate about including a bunch more stuff in
> posix.c.  Must it all be there, or would it be possible to move some
> of it out to our own gnulib-like mingw-w32.[ch] or something?

Most of it is already on a separate file, w32-proc.c (see the diffs).
I could take the macros at the beginning of posix.c and put them on a
separate .h file, if that would be better.  The rest of the changes in
posix.c are just moving #ifdef's around, more or less, and a few small
fragments of code, not unlike in other places.  I could, of course,
put them in separate functions, but the advantage of the patch I
pointed to is that it's well tested.

Thanks.

Message #22 received at 14361 <at> debbugs.gnu.org (full text, mbox):

From: Andy Wingo <wingo <at> pobox.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14361 <at> debbugs.gnu.org, ludo <at> gnu.org
Subject: Re: bug#14361: Building guile 2.0.9 under mingw + msys
Date: Tue, 21 Jun 2016 22:52:37 +0200

On Tue 21 Jun 2016 17:42, Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Andy Wingo <wingo <at> pobox.com>
>> Cc: 14361 <at> debbugs.gnu.org,  ludo <at> gnu.org
>> Date: Tue, 21 Jun 2016 17:06:05 +0200
>> 
>> Let's give it a go!  I understand that you do not want to work with
>> gnulib.  That's a negative from a Guile POV -- but it's not a
>> deal-breaker.
>
> I have nothing against Gnulib, but in this case their solution is
> simply not up to speed.
>
>> To that end I hesitate about including a bunch more stuff in
>> posix.c.  Must it all be there, or would it be possible to move some
>> of it out to our own gnulib-like mingw-w32.[ch] or something?
>
> Most of it is already on a separate file, w32-proc.c (see the diffs).
> I could take the macros at the beginning of posix.c and put them on a
> separate .h file, if that would be better.

That would be great, if you'd be amenable.  Thanks!

Andy

Message #25 received at 14361 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Wingo <wingo <at> pobox.com>
Cc: 14361 <at> debbugs.gnu.org, ludo <at> gnu.org
Subject: Re: bug#14361: Building guile 2.0.9 under mingw + msys
Date: Fri, 24 Jun 2016 12:51:45 +0300

> From: Andy Wingo <wingo <at> pobox.com>
> Cc: 14361 <at> debbugs.gnu.org,  ludo <at> gnu.org
> Date: Tue, 21 Jun 2016 22:52:37 +0200
> 
> On Tue 21 Jun 2016 17:42, Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Andy Wingo <wingo <at> pobox.com>
> >> Cc: 14361 <at> debbugs.gnu.org,  ludo <at> gnu.org
> >> Date: Tue, 21 Jun 2016 17:06:05 +0200
> >> 
> >> Let's give it a go!  I understand that you do not want to work with
> >> gnulib.  That's a negative from a Guile POV -- but it's not a
> >> deal-breaker.
> >
> > I have nothing against Gnulib, but in this case their solution is
> > simply not up to speed.
> >
> >> To that end I hesitate about including a bunch more stuff in
> >> posix.c.  Must it all be there, or would it be possible to move some
> >> of it out to our own gnulib-like mingw-w32.[ch] or something?
> >
> > Most of it is already on a separate file, w32-proc.c (see the diffs).
> > I could take the macros at the beginning of posix.c and put them on a
> > separate .h file, if that would be better.
> 
> That would be great, if you'd be amenable.  Thanks!

Done and posted on guile-devel.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.