|
From: | Thomas Thiriez |
Subject: | Re: 64-bit Guile on Windows |
Date: | Fri, 24 Mar 2023 00:14:56 +0100 |
User-agent: | mu4e 1.8.14; emacs 28.2 |
Hi Mike,I was able to build a 64-bit libguile 3 based on the branch wip-mingw. It appears to be working fine so far, and I am grateful for your work.
The only glitch I have found is that (gettimeofday) does not return correct values. It should return a pair (seconds . microseconds). The seconds part is correct, but the microseconds are often greater than 1000000, and can even be negative.
I am not sure how to fix it, but I believe I have found the root cause of the problem. The mingw implementation of the timeval struct is:
struct timeval { long tv_sec; long tv_usec; }; But the file guile/lib/sys/time.h replaces it with that: struct timeval { time_t tv_sec; long int tv_usec; };long is 32-bit on Windows, and time_t is 64-bit. When scm_gettimeofday calls gettimeofday(), that function expects a timeval with two longs, and the seconds and microseconds end up in the low and high parts of tv_sec. When scm_from_long is called on tv_sec, the 64-bit value is truncated, and the seconds are correctly converted. When converting the tv_usec member, however, we only get what happend to be there on the stack.
I have found a test in guile/m4/sys_time_h.m4 that enables the timeval replacement mentioned above when sizeof(tv_sec) is smaller than sizeof(time_t), with this accompanying comment:
On native Windows with a 64-bit 'time_t', 'struct timeval' is defined (in <sys/time.h> and <winsock2.h> for mingw64, in <winsock2.h> only
for MSVC) with a tv_sec field of type 'long' (32-bit!), which is smaller than the 'time_t' type mandated by POSIX. On OpenBSD 5.1 amd64, tv_sec is 64 bits and time_t 32 bits, but that is good enough.So I am left wondering how it is supposed to work if the timeval is replaced with members of a different size. Is scm_gettimeofday not calling the correct version of gettimeofday?
Another question. Are there more issues I can expect, while working with this wip-mingw branch? The name suggests it is not finished yet.
Regards, Thomas Thiriez Mike Gran <spk121@yahoo.com> writes:
On Tue, Nov 22, 2022 at 01:44:47PM +0100, Jean Abou Samra wrote:> Now, it is possible that the problem is that I am trying to > run a> .go file compiled on macOS on a Windows machine, and that the > two > platforms are different enough that the .go file can't be > reused. > And because I get that "Value out of range" error when > compiling> on Windows, I am probably stuck with .scm files instead of > compiled .go files. This bug is now hitting us too, we're investigating it here: https://gitlab.com/lilypond/lilypond/-/issues/6474 Best, JeanFor what it is worth, I do have functional 64-bit Guile 3.0.x for Windows at the link below, but that tree is still full of missteps and experiments and needs to made into a cleaner patchset. And I'm stillactively hacking there because I'm trying to a Guile that, onceinstalled, lives in a single directory like most Windows applicationsso I can make an MSIX installer. So it is a bit of a mess, but, I'm fairly confident the integers are fixed. https://github.com/spk121/guile/commits/wip-mingw-bleh That tree was based on, and will eventually contribute back to https://git.savannah.gnu.org/cgit/guile.git/log/?h=wip-mingwBoth of these trees require that you --enable-mini-gmp --enable-jit=no and --disable-lto at configure time.Regards, Mike Gran
[Prev in Thread] | Current Thread | [Next in Thread] |