Re: Current master doesn't build on Win10

[Andy Moreton]

On Fri 22 Oct 2021, Eli Zaretskii wrote:

>> From: Arash Esbati <arash@gnu.org>
>> Date: Fri, 22 Oct 2021 17:21:49 +0200
>> 
>> current master (commit f7a2ff3b) doesn't build with Msys2.  The message
>> is:
>> 
>> --8<---------------cut here---------------start------------->8---
>> make[1]: Entering directory '/z/pathto/emacs/lib-src'
>>   CC       ntlib.o
>>   RC       emacsclient.res
>>   CC       pop.o
>> In file included from 
>> z:/pathto/msys64/mingw64/x86_64-w64-mingw32/include/guiddef.h:154,
>>                  from 
>> z:/pathto/msys64/mingw64/x86_64-w64-mingw32/include/winnt.h:635,
>>                  from 
>> z:/pathto/msys64/mingw64/x86_64-w64-mingw32/include/minwindef.h:163,
>>                  from 
>> z:/pathto/msys64/mingw64/x86_64-w64-mingw32/include/windef.h:9,
>>                  from 
>> z:/pathto/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:69,
>>                  from ntlib.c:23:
>> ../lib/string.h:965:1: error: expected ',' or ';' before 
>> '_GL_ATTRIBUTE_MALLOC'
>>   965 | _GL_FUNCDECL_SYS (strdup, char *,
>>       | ^~~~~~~~~~~~~~~~
>> make[1]: *** [Makefile:418: ntlib.o] Error 1
>> make[1]: Leaving directory '/z/pathto/emacs/lib-src'
>> --8<---------------cut here---------------end--------------->8---
>> 
>> I'm not sure this is an Emacs issue or not.  GCC 11.2 landed also today
>> on my HD.  Can others reproduce this?
>
> lib/string.h is a Gnulib header, so I suggest to report this to
> bug-gnulib@gnu.org.  Or maybe it's some problem with MinGW64 headers
> (did that get updated as well recently?).  In any case, I just rebuilt
> the relevant files, and saw no problem (I'm a happy user of GCC 9.2.0).

I see this too. It seems to be an issue with gnulib and GCC 11.
Commenting  out this hunk from lib/string.in.h L456 works around the problem.

# if __GNUC__ >= 11 && !defined strdup
/* For -Wmismatched-dealloc: Associate strdup with free or rpl_free.  */
_GL_FUNCDECL_SYS (strdup, char *,
                  (char const *__s)
                  _GL_ARG_NONNULL ((1))
                  _GL_ATTRIBUTE_MALLOC _GL_ATTRIBUTE_DEALLOC_FREE);
# endif


Hopefully Paul Eggert will be along soon to come up with a proper fix in
gnulib.

    AndyM