Re: windows build failure

[Eli Zaretskii]

> Date: Fri, 20 Sep 2013 20:40:34 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
> 
> > From: Sean Sieger <address@hidden>
> > Date: Fri, 20 Sep 2013 12:34:28 -0400
> > 
> >     Does the below work as expected?
> > 
> >       emacs -Q c*.c
> > 
> >     If you do this from the src directory, you should end up with visiting
> >     the 14 C files that match the wildcard in the Emacs's src directory.
> >     What do you get in Emacs linked with the new MinGW runtime?
> > 
> > Wait, wait, wait ...
> > 
> > MinGW-Shell:
> > 
> > address@hidden /c/trunk/src/
> > $ emacs -Q c*.c
> > 
> > ... I get the correct result.
> 
> In the MSYS Bash, the shell does the wildcard expansion, that's why
> you get correct results.
> 
> > Command Prompt:
> > 
> > c:\trunk\src>emacs -Q c*.c
> > 
> > ... nope, visits the non-existent, `c*.c'.
> 
> Right, as I expected.
> 
> Here's why: MinGW runtime v4.x changed the layout of 'struct dirent',
> the structure returned by 'readdir', in an incompatible way.  Where
> previously we had
> [...]
> What happens in Emacs as result is that the startup code calls the
> Emacs implementation of 'readdir', which uses an incompatible 'struct
> dirent', and the result is that globbing of wildcards is broken.

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.

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