[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: windows build failure
From: |
Eli Zaretskii |
Subject: |
Re: windows build failure |
Date: |
Sat, 12 Oct 2013 19:49:18 +0300 |
> Date: Sat, 12 Oct 2013 08:55:14 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden
>
> Eli Zaretskii wrote:
> > This is because MinGW32 runtime 4.0 also moved
> > to using a 64-bit time_t type by default, which according to my
> > testing screws up Emacs
>
> What screwups do you observe?
Functions that expect 32-bit time_t values and pointers to such values
get 64-bit values/pointers instead.
> Are they limited to MinGW32
> or might they affect POSIXish 32-bit hosts with 64-bit time_t?
The former, of course. The problem is that MinGW developers tried to
find a way to adapt to the fact that the default system libc switched
to 64-bit time_t since Windows 7, but got confused between
compile-time decisions and run-time decisions. So building Emacs on
Windows 7 and running it there might still work, but if the binary
gets installed on XP, there will be problems.
The only workaround I found was to force 32-bit time_t (which is what
previous MinGW runtime was using anyway). MinGW developers promised
to fix that in the next release, but I will believe that when I see
it.
> The reason I'm asking is that on on 32-bit hosts,
> Emacs's hacky representation of time values is
> limited to time_t values in the range [- 2**45, 2**45),
> and Emacs reports an error via time_overflow when asked
> to compute a time out of that range, even if it is operating
> on a platform with 64-bit time_t values. So, if you set your
> system clock to 1116918-05-14 19:20:32 UTC on such a host,
> or otherwise deal with outlandish time stamps, Emacs will
> have screwups, and it won't be trivial to fix this.
So you are saying that 32-bit hosts will be dead for Emacs in about
half a year (if I interpret that time stamp correctly), is that right?
Re: windows build failure, Sean Sieger, 2013/10/12
Re: windows build failure, Sean Sieger, 2013/10/14
Re: windows build failure, Sean Sieger, 2013/10/14