bug#10310: Guile fails to bootstrap on Debian unstable

[Ludovic Courtès]

Hi,

This was fixed in commit 8f47877fc7a9f36ffcfba7d63c5cdf8ebe40347a, so
closing.

Thanks!

Ludo’.

bug#10336: Holidays vs. release

[Ludovic Courtès]

Hello!

l...@gnu.org (Ludovic Courtès) skribis:

>  skribis:
>
>> I'm on a 32bit Debian intel system.  libgc is 7.2alpha4
>>
>> git describe is
>> v2.0.3-82-ga2c6601
>>
>> The single failure running make check is
>>
>> Running gc.test
>> FAIL: gc.test: gc: Lexical vars are collectable
>
> Same problem on Hydra, but only i686, not x86_64.

So I looked into it, and there’s at least one thing wrong: the test must
be compiled with #:partial-eval? #f, otherwise the ‘let’ vanishes, which
defeats the test.

Second thing, it suffices to insert a function call like
((lambda (x) #f) #f) just before calls to ‘gc’ to solve the problem.

So I’m thinking we may have a real bug here.

I’ve changed the test this way:

  (pass-if "Lexical vars are collectable"
(pair?
 (compile
  '(begin
 (define guardian (make-guardian))
 (let ((f (list 1 2 3)))
(guardian f))

 ;; Note: no `stack-cleanup' call should be needed here since
 ;; leaving `let' should have the same effect.

 ;((lambda (x) x) #f)
 (gc)(gc)(gc)
 (guardian))

  ;; Turn the partial evaluator off so that `let' is preserved.
  #:opts '(#:partial-eval? #f)
  #:env (current-module

The assembly code does seem to push ‘void’ in all cases, though, but
this needs to be double-checked.

Thanks,
Ludo’.

bug#10336: Holidays vs. release

[Andy Wingo]

Hi Ludovic,

I pushed a couple patches that should help this bug out, though for some
reason I wasn't able to reproduce the issue before.  I wonder why.

On Wed 25 Jan 2012 17:10, l...@gnu.org (Ludovic Courtès) writes:

> So I looked into it, and there’s at least one thing wrong: the test must
> be compiled with #:partial-eval? #f, otherwise the ‘let’ vanishes, which
> defeats the test.

Indeed.  I think I fixed that now.

> Second thing, it suffices to insert a function call like
> ((lambda (x) #f) #f) just before calls to ‘gc’ to solve the problem.

Strange.  Another thing was that the function was a constant, not a
closure, so it wasn't going to be collectable in the first place.

Can you retry the test now, Dale?

Thanks,

Andy
-- 
http://wingolog.org/

bug#10336: Holidays vs. release

[Ludovic Courtès]

Hello,

Andy Wingo  skribis:

> I pushed a couple patches that should help this bug out,

As I wrote, it doesn’t solve the problem.  :-/

However, I suspect it’s just one or two words on the stack that fail to
be cleared, which is why I ended up looking at the assembly in search of
a real bug.

> Can you retry the test now, Dale?

It’s retried at every commit.  ;-)

  http://hydra.nixos.org/jobset/gnu/guile-2-0/

(It’s on i686-linux-gnu.)

Ludo’.

bug#10474: Building guile 2.x under mingw + msys

[Ludovic Courtès]

Hi Eli,

Thanks for doing all the hard work!

I’m willing to apply your changes, but could you send them in ‘git
format-patch’ format, with a log in GNU ChangeLog style, to make it
easier?

In prevision of the of an increased contribution rate ;-), could you
assign copyright to the FSF?  At first sight, these patches may be
applicable without copyright assignment, but that’s the limit, I think.

Eli Zaretskii  skribis:

> 1. Compilation warnings in deprecation.c:
>
>SNARF  deprecation.x
>  deprecation.c:40:1: warning: "vsnprintf" redefined
>  In file included from deprecation.c:25:
>  ../lib/stdio.h:1605:1: warning: this is the location of the previous 
> definition
>
> This is because deprecation.c does this:
>
>  /* Windows defines. */
>  #ifdef __MINGW32__
>  #define vsnprintf _vsnprintf
>  #endif
>
> but lib/stdio.h already did the same.  My solution was to add an
> "#ifdef vsnprintf" condition to deprecation.c to avoid redefinition.
>
> 2. Compilation warning in expand.c:
>
>SNARF  expand.x
>  expand.c:52:1: warning: "VOID" redefined
>  In file included from d:/usr/include/windef.h:253,
> from d:/usr/include/windows.h:48,
> from d:/usr/include/winsock2.h:22,
> from ../libguile/iselect.h:36,
> from ../libguile/threads.h:30,
> from ../libguile/gc.h:29,
> from ../libguile/_scm.h:75,
> from expand.c:27:
>  d:/usr/include/winnt.h:75:1: warning: this is the location of the 
> previous definition
>  expand.c:54:1: warning: "CONST" redefined
>  In file included from d:/usr/include/windows.h:48,
> from d:/usr/include/winsock2.h:22,
> from ../libguile/iselect.h:36,
> from ../libguile/threads.h:30,
> from ../libguile/gc.h:29,
> from ../libguile/_scm.h:75,
> from expand.c:27:
>  d:/usr/include/windef.h:39:1: warning: this is the location of the 
> previous definition
>
> This is because expand.c does:
>
>  #define VOID(src) \
>SCM_MAKE_EXPANDED_VOID(src)
>  #define CONST(src, exp) \
>SCM_MAKE_EXPANDED_CONST(src, exp)
>
> and Windows headers have their own definitions for VOID and CONST.
>
> My solution was to add this to expand.c:
>
>  #ifdef VOID
>  #undef VOID
>  #endif
>  #ifdef CONST
>  #undef CONST
>  #endif
>
> However, I really suggest that expand.c uses some less ubiquitous
> symbol names, like SCM_CONST and SCM_VOID.
>
> 3. Compilation warning in filesys.c:
>
>SNARF  filesys.x
>  filesys.c:119:1: warning: "mkdir" redefined
>  In file included from ../lib/sys/stat.h:47,
> from filesys.c:92:
>  ../lib/sys/stat.h:808:1: warning: this is the location of the previous 
> definition
>
> This is because filesys.c does this:
>
>  /* Some more definitions for the native Windows port. */
>  #ifdef __MINGW32__
>  # define mkdir(path, mode) mkdir (path)
>
> But gnulib already redirected `mkdir' to its replacement function.  My
> solution: don't define if already redirected.  To that end, I added
> the following condition before the above #define:
>
>  /* When configured to use the gnulib replacement, don't redefine
>   mkdir, as it is already redirected to the replacement, see
>   lib/sys/stat.h.  */
>  # if !GNULIB_defined_rpl_mkdir
>
> I'm not sure using GNULIB_defined_rpl_mkdir is TRT here, but I didn't
> find a better way.

Strangely enough, the cross-build to MinGW32 at
 is not showing any of
these.  Any idea why?  That’s with MinGW 3.18.

> 4. Missing setenv needed by dynl.c:
>
>CC dynl.lo
>  dynl.c: In function `augment_env':
>  dynl.c:141: warning: implicit declaration of function `setenv'
>
> Solution: add a setenv implementation.  However, I think Guile would
> be better off using a more portable putenv instead.

I’ll try Gnulib’s setenv module.

> 5. Compilation error in net_db.c:

[...]

> is inappropriate when gnulib was used to wrap Windows socket
> functions.  When gnulib _is_ used, the missing macros are already
> defined by lib/sys/socket.h.  Therefore, I modified the condition to:
>
>  #if HAVE_WINSOCK2_H && !GNULIB_TEST_SOCKET
>  #include 
>  # if HAVE_WS2TCPIP_H
>  #  include 
>  # endif
>  #else
>  #include 
>  #include 
>  #include 
>  #include 
>  #endif
>
> using GNULIB_TEST_SOCKET as evidence that gnulib is being used.  I'm
> not sure GNULIB_TEST_SOCKET is TRT, but I saw no better candidate.
> Maybe gnulib should provide us with a better macro.

This seems to be the right thing, according to gnulib-common.m4:

--8<---cut here---start->8---
# gl_MODULE_INDICATOR_FOR_TESTS([modulename])
# defines a C macro indicatin

bug#10336: Holidays vs. release

[Andy Wingo]

Hi,

On Wed 25 Jan 2012 21:34, l...@gnu.org (Ludovic Courtès) writes:

> Andy Wingo  skribis:
>
>> I pushed a couple patches that should help this bug out,
>
> As I wrote, it doesn’t solve the problem.  :-/

Ah sorry, I misunderstood.

> I suspect it’s just one or two words on the stack that fail to be
> cleared, which is why I ended up looking at the assembly in search of
> a real bug.

Interesting.  That would explain why it would be architecture-specific,
as well.

Thanks for the patience :)

Andy
-- 
http://wingolog.org/

bug#10336: Holidays vs. release

[dsmich]

 Andy Wingo  wrote: 
> Hi Ludovic,
> 
> I pushed a couple patches that should help this bug out, though for some
> reason I wasn't able to reproduce the issue before.  I wonder why.
> 
> On Wed 25 Jan 2012 17:10, l...@gnu.org (Ludovic Courtès) writes:
> 
> > So I looked into it, and there’s at least one thing wrong: the test must
> > be compiled with #:partial-eval? #f, otherwise the ‘let’ vanishes, which
> > defeats the test.
> 
> Indeed.  I think I fixed that now.
> 
> > Second thing, it suffices to insert a function call like
> > ((lambda (x) #f) #f) just before calls to ‘gc’ to solve the problem.
> 
> Strange.  Another thing was that the function was a constant, not a
> closure, so it wasn't going to be collectable in the first place.
> 
> Can you retry the test now, Dale?

Sure.  v2.0.3-190-gf5e772b still has the same failure.

-Dale

bug#10474: Building guile 2.x under mingw + msys

[Eli Zaretskii]

> From: l...@gnu.org (Ludovic Courtès)
> Cc: 10...@debbugs.gnu.org,  commander.si...@googlemail.com
> Date: Wed, 25 Jan 2012 22:12:04 +0100
> 
> Thanks for doing all the hard work!

Thanks for developing Guile.

> I’m willing to apply your changes, but could you send them in ‘git
> format-patch’ format, with a log in GNU ChangeLog style, to make it
> easier?

I can certainly add ChangeLog entries, but `git format-patch' would be
harder.  I don't have git installed on my development machine (git is
a bit of PITA on Windows).  What's wrong with "diff -u"?  I can divide
the diffs into separate chunks of related changes, so it will be
easier for you to produce separate commits, if that's what you want
from `git format-patch'.  If there's another reason for your request,
please tell what that is and I will try to make your job easier as
much as I can.  But installing git and cloning the Guile repo just to
submit these changes is something I'd like to avoid if possible.

> In prevision of the of an increased contribution rate ;-), could you
> assign copyright to the FSF?

Will do.

> Strangely enough, the cross-build to MinGW32 at
>  is not showing any of
> these.  Any idea why?  That’s with MinGW 3.18.

I have exactly zero experience with the cross-build MinGW
environment.  My MinGW installation is 3.14, FWIW.

> > is inappropriate when gnulib was used to wrap Windows socket
> > functions.  When gnulib _is_ used, the missing macros are already
> > defined by lib/sys/socket.h.  Therefore, I modified the condition to:
> >
> >  #if HAVE_WINSOCK2_H && !GNULIB_TEST_SOCKET
> >  #include 
> >  # if HAVE_WS2TCPIP_H
> >  #  include 
> >  # endif
> >  #else
> >  #include 
> >  #include 
> >  #include 
> >  #include 
> >  #endif
> >
> > using GNULIB_TEST_SOCKET as evidence that gnulib is being used.  I'm
> > not sure GNULIB_TEST_SOCKET is TRT, but I saw no better candidate.
> > Maybe gnulib should provide us with a better macro.
> 
> This seems to be the right thing, according to gnulib-common.m4:

OK.