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.