Re: Emacs build fails on Windows mingw64

[Andy Moreton <andrewjmoreton@gmail.com>]

On Sun 24 Oct 2021, Eli Zaretskii wrote:

>> From: Paul Eggert <eggert@cs.ucla.edu>
>> Date: Sat, 23 Oct 2021 23:45:04 -0400
>> Cc: bug-gnulib@gnu.org, emacs-devel@gnu.org
>> 
>> On 10/23/21 4:42 PM, Andy Moreton wrote:
>> > Can this issue be addressed in gnulib so the emacs bug can be fixed ?
>> 
>> This appears to be an issue in Emacs not Gnulib, as a few of Emacs's 
>> MS-Windows-specific files don't include <config.h> first, which is a 
>> documented requirement for Gnulib-using apps. Proposed Emacs patch 
>> attached. I haven't tested or installed this, as I don't use MingW.
>
> This solution cannot be used, because ntlib cannot include config.h,
> due to various redefinitions and redirections we do in ms-w32.h for
> Emacs.  (We could redesign these tricks, but that's a lot of tedium,
> and cannot be done on the release branch anyway.)

An alternative workaround in ntlib.c is to add the missing defines
before including <windows.h>:

#define _GL_ATTRIBUTE_MALLOC
#define _GL_ATTRIBUTE_DEALLOC_FREE

That bootstraps on emacs-28.

> Let me turn the table and ask why that declaration of strdup is at all
> needed in Gnulib's string.h when it's used in MinGW builds?  strdup is
> available natively in the MS C runtime, and its prototype is already
> in the system's string.h header.  I'm aware that Gnulib has strdup.c,
> but we don't currently use it in Emacs, and even if we will at some
> point, we won't use it in the MinGW build.  So how about ifdef-ing
> that declaration away for MinGW in the Gnulib header?

That would be less likely to need further atention each time that emacs
is updated to import updated gnulib files.

    AndyM