guile-devel
[Top][All Lists]
Advanced

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

Re: Guile 2.2 on MSYS2 + MinGW


From: Matthew Keeter
Subject: Re: Guile 2.2 on MSYS2 + MinGW
Date: Tue, 23 Jan 2018 21:18:17 -0500

On Jan 18, 2018, at 11:00 AM, Eli Zaretskii <address@hidden> wrote:

From: Matthew Keeter <address@hidden>
Date: Thu, 18 Jan 2018 10:18:36 -0500

Yup, I’m building 2.2.3.  I see mktime.c in guile-2.2.3/lib, but do not see
mktime.o when I objdump libgnu.a, indicating that it’s not being built.

In config.log, I see a few lines that could be relevant:

configure:34662: checking for working mktime
...
gl_cv_func_working_mktime=yes
...
GNULIB_MKTIME=‘1'
...
REPLACE_MKTIME=‘0'
...
gl_GNULIB_ENABLED_mktime_FALSE='#'
gl_GNULIB_ENABLED_mktime_TRUE=‘'

(full config.log is here: https://gist.github.com/mkeeter/81c273069a2804ad8d53e72533f6f8da)

Does this offer any insight?  I’m confused by the conflicting GNULIB_MKTIME vs
gl_GNULIB_ENABLED_mktime_TRUE, but am not adept at parsing automake outputs…

Then this sounds like a bug in Gnulib: it determines that your
platform doesn't need mktime, but it "forgets" that timegm, which your
platform does need, depends on mktime.

So I suggest to report this to the Gnulib mailing list, and I hope
they will propose a solution.  Meanwhile, you can continue the build
by copy/pasting the source of mktime.c into some Gnulib source that is
being compiled (e.g. timegm.c, which needs it in the first place), and
re-running "make".

I’ve added another patch [1] which works around this gnulib bug.

The 32-bit build now completes and makes its way past the snarfing issue
that I was seeing in the 64-bit build!  Now, it's failing at the bootstrap stage:

  BOOTSTRAP GUILEC ice-9/eval.go
;;; note: source file C:/msys64/home/mkeeter/guile/src/guile-2.2.3/module/ice-9/boot-9.scm
;;;       newer than compiled C:/msys64/home/mkeeter/guile/src/guile-2.2.3/prebuilt/32-bit-little-endian/ice-9/boot-9.go
Backtrace:
           8 (apply-smob/1 #<catch-closure 4fba0e0>)
In ice-9/eval.scm:
   657:36  7 (_ _)
    619:8  6 (_ #(#(#<directory (guile-user) 4fdcb40>)))
    155:9  5 (_ _)
    619:8  4 (_ #(#(#(#(#(#(#(#(#(#(#(#) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒))
    159:9  3 (_ #(#(#(#(#(#(#(#(#(#(#(#) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒))
   223:20  2 (proc #(#(#(#(#(#(#(#(#(#(# ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒) ▒))
In unknown file:
           1 (%resolve-variable (7 . SIGINT) #<directory (scripts co▒>)
           0 (_ #<procedure 62ef720 at ice-9/eval.scm:330:13 ()> #<▒> ▒)

ERROR: Unbound variable: SIGINT

If I boot up the interpreter, it too does not know about SIGINT:

address@hidden MINGW32 ~/guile/src/build-i686-w64-mingw32
$ GUILE_AUTO_COMPILE=0 GUILE_LOAD_PATH=/home/mkeeter/guile/src/guile-2.2.3/module ./meta/build-env guile
GNU Guile 2.2.3
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> SIGINT
ice-9/eval.scm:619:8: In procedure module-lookup: Unbound variable: SIGINT

On my Mac, the variable is defined (and has a value of 2).

I believe the odd printing is a quirk of the MinGW terminal – it certainly doesn’t help in
debugging, but I think the fundamental issue here is Guile not knowing about SIGINT.

Any suggestions for next steps?

Thanks,
Matt


reply via email to

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