[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 64-bit Guile on Windows

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.

Thomas Thiriez

Mike Gran <> 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:


For 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 still
actively hacking there because I'm trying to a Guile that, once
installed, lives in a single directory like most Windows applications
so I can make an MSIX installer. So it is a bit of a mess, but,
I'm fairly confident the integers are fixed.

That tree was based on, and will eventually contribute
back to

Both of these trees require that you --enable-mini-gmp --enable-jit=no and --disable-lto at configure time.

Mike Gran

reply via email to

[Prev in Thread] Current Thread [Next in Thread]