Guile 2.2 on MSYS2 + MinGW

Guile 2.2 on MSYS2 + MinGW

[Matthew Keeter]

[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]

I’m dipping my toe into the tarpit of making a native Windows build for Guile 2.2,
using msys2 (http://www.msys2.org/ <http://www.msys2.org/>).  My efforts are here:
    https://github.com/mkeeter/guile-mingw <https://github.com/mkeeter/guile-mingw>https://github <https://github/>.com/mkeeter/guile-mingw

So far, I’ve adapted or created a handful of patches, and have successfully
built guile.exe.  The build is failing after this point, when it tries to build the
documentation (?):

make[3]: Entering directory '/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile'
  GEN      guile-procedures.texi
Backtrace:
           0 (primitive-load-path "C:/msys64/home/mkeeter/guile/src/▒")

ERROR: In procedure primitive-load-path:
ERROR: In procedure primitive-load-path: Unable to find file "C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile/C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/meta/guild" in load path

Does anyone have tips for why primitive-load-path would be failing like this?

Thanks,
Matt

p.s.  I’d prefer to focus on one issue at a time, but in case you’re wondering, the guile.exe
that it has built is… eccentric.  To get anywhere, I have to run it with auto-compilation turned off,
and even then, it’s non-functional:

mkeeter@MATTHEWKEETA8AA MINGW64 ~/guile/src/build-x86_64-w64-mingw32
$ GUILE_AUTO_COMPILE=0 ./meta/build-env guile
GNU Guile 2.2.0
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)> (+ 1 2)
While compiling expression:
ERROR: In procedure bytevector-u64-set!: Value out of range: -149659645

[-- Attachment #2: Type: text/html, Size: 5438 bytes --]

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter <matt.j.keeter@gmail.com>
> Date: Tue, 16 Jan 2018 17:50:58 -0500
> 
> So far, I’ve adapted or created a handful of patches, and have successfully
> built guile.exe.  The build is failing after this point, when it tries to build the
> documentation (?):
> 
> make[3]: Entering directory '/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile'
>   GEN      guile-procedures.texi
> Backtrace:
>            0 (primitive-load-path "C:/msys64/home/mkeeter/guile/src/▒")

What is the system locale of your Windows machine?  That funny
character might mean you have problems with non-ASCII characters, due
to bugs in libunistring.  And even if you locale is English_USA, you
should still know that libunistring will give you trouble: the version
of it distributed by MSYS2 have a couple of grave bugs that make
character encoding conversions fail on MS-Windows, and since Guile
works in UTF-8 internally, you will have problems in with any
primitives that need to work with non-ASCII characters.  For that
reason, I recommend building the latest version of libunistring first,
as the bugs I discovered back when I was porting Guile 2.0 to MinGW
are now fixed in up-stream libunistring (but MSYS2 still offers the
old version, and the patches it uses don't include those needed to fix
those problems).

> ERROR: In procedure primitive-load-path:
> ERROR: In procedure primitive-load-path: Unable to find file
> "C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile/C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/meta/guild"
> in load path
> 
> Does anyone have tips for why primitive-load-path would be failing like this?

This looks like some code which doesn't consider C:/foo/bar an
absolute file name, so it prepends the current directory to it.  These
problems are supposed to be fixed by patches I submitted for v2.0, but
maybe there's some new code in 2.2 that needs similar treatment.

> Enter `,help' for help.
> scheme@(guile-user)> (+ 1 2)
> While compiling expression:
> ERROR: In procedure bytevector-u64-set!: Value out of range: -149659645

Sounds like overflow?  You should be aware that 64-bit Windows uses
the LLP64 model, whereas Unix and Linux use LP64.  In practice, this
means that every variable whose type is 'long' or 'unsigned long' is a
64-bit type on 64-bit Unix systems, but a 32-bit type on Windows, so
all such variables should be carefully audited to makesure they don't
have to be converted to the corresponding 64-bit types.  For that
reason, my suggestion would be to build a 32-bit port of Guile first
(AFAIK, Mingw64 and MSYS2 support that), and only switch to 64 bits
once you have the 32-bit port up and running, and it passes the test
suite.

Re: Guile 2.2 on MSYS2 + MinGW

[Matthew Keeter]

[-- Attachment #1: Type: text/plain, Size: 3815 bytes --]

Following your advice, I’m now trying to build a 32-bit version under MinGW,
This fails a little earlier in the process:

make[2]: Entering directory '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
make  all-am
make[3]: Entering directory '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
  CCLD     libguile-2.2.la
../lib/.libs/libgnu.a(timegm.o):timegm.c:(.text+0x22): undefined reference to `mktime_internal'
collect2.exe: error: ld returned 1 exit status
make[3]: *** [Makefile:2373: libguile-2.2.la] Error 1

This appears to be the same bug as #24681
(http://lists.gnu.org/archive/html/bug-guile/2017-03/msg00095.html <http://lists.gnu.org/archive/html/bug-guile/2017-03/msg00095.html>),
but I don’t see anyone successfully resolving it
(and I can’t find any references to it in the Git history).

Any ideas?

Thanks,
Matt

> On Jan 17, 2018, at 10:54 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Matthew Keeter <matt.j.keeter@gmail.com>
>> Date: Tue, 16 Jan 2018 17:50:58 -0500
>> 
>> So far, I’ve adapted or created a handful of patches, and have successfully
>> built guile.exe.  The build is failing after this point, when it tries to build the
>> documentation (?):
>> 
>> make[3]: Entering directory '/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile'
>>  GEN      guile-procedures.texi
>> Backtrace:
>>           0 (primitive-load-path "C:/msys64/home/mkeeter/guile/src/▒")
> 
> What is the system locale of your Windows machine?  That funny
> character might mean you have problems with non-ASCII characters, due
> to bugs in libunistring.  And even if you locale is English_USA, you
> should still know that libunistring will give you trouble: the version
> of it distributed by MSYS2 have a couple of grave bugs that make
> character encoding conversions fail on MS-Windows, and since Guile
> works in UTF-8 internally, you will have problems in with any
> primitives that need to work with non-ASCII characters.  For that
> reason, I recommend building the latest version of libunistring first,
> as the bugs I discovered back when I was porting Guile 2.0 to MinGW
> are now fixed in up-stream libunistring (but MSYS2 still offers the
> old version, and the patches it uses don't include those needed to fix
> those problems).
> 
>> ERROR: In procedure primitive-load-path:
>> ERROR: In procedure primitive-load-path: Unable to find file
>> "C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/libguile/C:/msys64/home/mkeeter/guile/src/build-x86_64-w64-mingw32/meta/guild"
>> in load path
>> 
>> Does anyone have tips for why primitive-load-path would be failing like this?
> 
> This looks like some code which doesn't consider C:/foo/bar an
> absolute file name, so it prepends the current directory to it.  These
> problems are supposed to be fixed by patches I submitted for v2.0, but
> maybe there's some new code in 2.2 that needs similar treatment.
> 
>> Enter `,help' for help.
>> scheme@(guile-user)> (+ 1 2)
>> While compiling expression:
>> ERROR: In procedure bytevector-u64-set!: Value out of range: -149659645
> 
> Sounds like overflow?  You should be aware that 64-bit Windows uses
> the LLP64 model, whereas Unix and Linux use LP64.  In practice, this
> means that every variable whose type is 'long' or 'unsigned long' is a
> 64-bit type on 64-bit Unix systems, but a 32-bit type on Windows, so
> all such variables should be carefully audited to makesure they don't
> have to be converted to the corresponding 64-bit types.  For that
> reason, my suggestion would be to build a 32-bit port of Guile first
> (AFAIK, Mingw64 and MSYS2 support that), and only switch to 64 bits
> once you have the 32-bit port up and running, and it passes the test
> suite.


[-- Attachment #2: Type: text/html, Size: 6471 bytes --]

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter <matt.j.keeter@gmail.com>
> Date: Wed, 17 Jan 2018 17:30:02 -0500
> Cc: guile-devel@gnu.org
> 
> Following your advice, I’m now trying to build a 32-bit version under MinGW,
> This fails a little earlier in the process:
> 
> make[2]: Entering directory '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
> make  all-am
> make[3]: Entering directory '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
>   CCLD     libguile-2.2.la
> ../lib/.libs/libgnu.a(timegm.o):timegm.c:(.text+0x22): undefined reference to `mktime_internal'
> collect2.exe: error: ld returned 1 exit status
> make[3]: *** [Makefile:2373: libguile-2.2.la] Error 1
> 
> This appears to be the same bug as #24681
> (http://lists.gnu.org/archive/html/bug-guile/2017-03/msg00095.html),
> but I don’t see anyone successfully resolving it
> (and I can’t find any references to it in the Git history).
> 
> Any ideas?

mktime_internal is in Gnulib's mktime.c.  What version of Guile 2.2.x
are you building?  The latest v2.2.3 includes mktime.c in
guile-2.2.3/lib/, do you have it?  If you do have it, do you see
mktime.o in libgnu.a?

If mktime.c is in the tree, but is not compiled, you need to
investigate why, by looking at config.log, where the configure script
determines whether your system needs mktime.c and/or mktime_internal.

Re: Guile 2.2 on MSYS2 + MinGW

[Matthew Keeter]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

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…

-Matt

> On Jan 18, 2018, at 9:09 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Matthew Keeter <matt.j.keeter@gmail.com>
>> Date: Wed, 17 Jan 2018 17:30:02 -0500
>> Cc: guile-devel@gnu.org
>> 
>> Following your advice, I’m now trying to build a 32-bit version under MinGW,
>> This fails a little earlier in the process:
>> 
>> make[2]: Entering directory '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
>> make  all-am
>> make[3]: Entering directory '/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile'
>>  CCLD     libguile-2.2.la
>> ../lib/.libs/libgnu.a(timegm.o):timegm.c:(.text+0x22): undefined reference to `mktime_internal'
>> collect2.exe: error: ld returned 1 exit status
>> make[3]: *** [Makefile:2373: libguile-2.2.la] Error 1
>> 
>> This appears to be the same bug as #24681
>> (http://lists.gnu.org/archive/html/bug-guile/2017-03/msg00095.html),
>> but I don’t see anyone successfully resolving it
>> (and I can’t find any references to it in the Git history).
>> 
>> Any ideas?
> 
> mktime_internal is in Gnulib's mktime.c.  What version of Guile 2.2.x
> are you building?  The latest v2.2.3 includes mktime.c in
> guile-2.2.3/lib/, do you have it?  If you do have it, do you see
> mktime.o in libgnu.a?
> 
> If mktime.c is in the tree, but is not compiled, you need to
> investigate why, by looking at config.log, where the configure script
> determines whether your system needs mktime.c and/or mktime_internal.


[-- Attachment #2: Type: text/html, Size: 4310 bytes --]

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter <matt.j.keeter@gmail.com>
> 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".

Re: Guile 2.2 on MSYS2 + MinGW

[Matthew Keeter]

[-- Attachment #1: Type: text/plain, Size: 3598 bytes --]

> On Jan 18, 2018, at 11:00 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Matthew Keeter <matt.j.keeter@gmail.com>
>> 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:

mkeeter@MATTHEWKEETA8AA 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

[1] https://github.com/mkeeter/guile-mingw/blob/master/0006-timegm-i686.mingw.patch

[-- Attachment #2: Type: text/html, Size: 15278 bytes --]

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter <matt.j.keeter@gmail.com>
> Date: Tue, 23 Jan 2018 21:18:17 -0500
> Cc: guile-devel@gnu.org
> 
>   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:
> 
> mkeeter@MATTHEWKEETA8AA 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).

You should grep the libguile directory for "SIGINT" and make sure the
file(s) involved in defining that variable are compiled in your build.
(The MinGW port of Guile 2.0.11 I have here does know about SIGINT,
FWIW.)

> 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.

Yes, but you should also look into the printing issue, as that
shouldn't happen.  It's a problem of some sort, perhaps Guile thinks
your terminal is UTF-8 capable or something.

Re: Guile 2.2 on MSYS2 + MinGW

[Matthew Keeter]

[-- Attachment #1: Type: text/plain, Size: 3136 bytes --]

> On Jan 24, 2018, at 1:57 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Matthew Keeter <matt.j.keeter@gmail.com>
>> Date: Tue, 23 Jan 2018 21:18:17 -0500
>> Cc: guile-devel@gnu.org
>> 
>>  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:
>> 
>> mkeeter@MATTHEWKEETA8AA 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).
> 
> You should grep the libguile directory for "SIGINT" and make sure the
> file(s) involved in defining that variable are compiled in your build.
> (The MinGW port of Guile 2.0.11 I have here does know about SIGINT,
> FWIW.)
> 
>> 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.
> 
> Yes, but you should also look into the printing issue, as that
> shouldn't happen.  It's a problem of some sort, perhaps Guile thinks
> your terminal is UTF-8 capable or something.


Well, that was an obvious problem:  I had configured the build with --without-posix, which I guess is no longer supported.

Unfortunately, the rebuild is now back to having trouble with building the documentation, with the same error as before:

ERROR: In procedure primitive-load-path:
In procedure primitive-load-path: Unable to find file "C:/msys64/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile/C:/msys64/home/mkeeter/guile/src/build-i686-w64-mingw32/meta/guild" in load path

Time to strap a bunch of instrumentation onto load.c and see where this is coming from…

-Matt

[-- Attachment #2: Type: text/html, Size: 5214 bytes --]

Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter <matt.j.keeter@gmail.com>
> Date: Thu, 25 Jan 2018 09:54:40 -0500
> Cc: guile-devel@gnu.org
> 
> Well, that was an obvious problem:  I had configured the build with --without-posix, which I guess is no longer
> supported.

I don't know if it's supported, but it definitely is not needed for
the MS-Windows build.

> ERROR: In procedure primitive-load-path:
> In procedure primitive-load-path: Unable to find file
> "C:/msys64/home/mkeeter/guile/src/build-i686-w64-mingw32/libguile/C:/msys64/home/mkeeter/guile/src/build-i686-w64-mingw32/meta/guild"
> in load path
> 
> Time to strap a bunch of instrumentation onto load.c and see where this is coming from…

Yes, I think you will find that some code there doesn't know about the
Windows C:/foo/bar form of absolute file names.  Although
is_absolute_file_name and is_file_name_separator are in load.c,
and AFAICT do TRT for MinGW...  So maybe the problem is in some .scm
file instead.  Search for literals slash '/' characters to find some
potential offenders.