[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: windows build failure
From: |
Sean Sieger |
Subject: |
Re: windows build failure |
Date: |
Mon, 14 Oct 2013 14:02:56 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (windows-nt) |
C:\trunk\src\emacs -Q c*.c
Gives the correct result.
Eli Zaretskii <address@hidden> writes:
I tried to fix this problem in trunk revision 114637. If you (or
someone else who would like to move to the new MinGW runtime) have
time, please re-test with v4.0 of the MinGW runtime.
Please also try the various time-related functions, such as
decode-time, encode-time, format-time-string, and
current-time-string. 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, especially if it was built on Windows 7 and
then run on XP. So for now, I forced the MinGW32 headers to use a
32-bit time_t type. This needs to be thoroughly tested, though.
Thanks.
Sorry, how to `try' decode-time, encode-time, format-time-string, and
current-time-string? I am reading *Help* on each ...
> At the time, I tried to convince the MinGW developers not to do this,
> here:
>
> http://sourceforge.net/mailarchive/message.php?msg_id=29278605
> http://sourceforge.net/mailarchive/message.php?msg_id=30712991
> http://sourceforge.net/mailarchive/message.php?msg_id=30715094
> http://sourceforge.net/mailarchive/message.php?msg_id=30854291
>
> Evidently, I failed completely to convince them, as the incompatible
> runtime went to print regardless, and the problems will now begin
> unfolding before our eyes...
Well, it turns out the MinGW developers might be listening after all,
at least to some of the arguments: I'm promised that the next release
of the runtime will not call opendir/readdir from the startup code.
We shall see...
Thank you, Eli.
Re: windows build failure, Sean Sieger, 2013/10/12
Re: windows build failure, Sean Sieger, 2013/10/14
Re: windows build failure,
Sean Sieger <=