Re: 64-bit Guile on Windows

[Thomas Thiriez via General Guile related discussions <guile-user@gnu.org>]

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,
>> Jean
>> 
>
>
> 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.
>
> 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-mingw
>
> Both of these trees require that you  --enable-mini-gmp 
> --enable-jit=no and --disable-lto at configure time.
>
> Regards,
> Mike Gran