Re: Guile 2.2 on MSYS2 + MinGW

[Eli Zaretskii]

> From: Matthew Keeter <address@hidden>
> 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.