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 <e...@gnu.org> wrote: > >> 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.
