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 <spk...@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
