> From: Matthew Keeter <matt.j.kee...@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.
