Current master doesn't build on Win10

Current master doesn't build on Win10

[Arash Esbati]

Hi all,

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?

Best, Arash

Re: Current master doesn't build on Win10

[Eli Zaretskii]

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

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

Re: Current master doesn't build on Win10

[Arash Esbati]

Eli Zaretskii <eliz@gnu.org> writes:

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

Thanks for your response.  I will investigate further to see what's
going wrong.

Best, Arash

Re: Current master doesn't build on Win10 (nor does emacs-28)

[Andy Moreton]

On Sat 23 Oct 2021, Andy Moreton wrote:

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

Note that this problem also occurs on emacs-28, and the workaround above
also works. Thus this needs a gnulib fix before the release.

    AndyM

Re: Current master doesn't build on Win10 (nor does emacs-28)

[H. Dieter Wilhelm]

Andy Moreton <andrewjmoreton@gmail.com> writes:

> On Sat 23 Oct 2021, Andy Moreton wrote:
>
>> 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.
>
> Note that this problem also occurs on emacs-28, and the workaround above
> also works. Thus this needs a gnulib fix before the release.

I can't reproduce this for the emacs-28 branch with a pull from
yesterday evening! It seems that

make bootstrap

make install

is running through without any errors.  The MSYS2 and MinGW collections
are quite recent, but it seems gcc 11 is not installed.  gcc --version
=> 10.3.0

Configured for 'x86_64-w64-mingw32'.

  Where should the build process find the source code?    .
  What compiler should emacs be built with?               gcc  -g3 -O2 -gdwarf-2
  Should Emacs use the GNU version of malloc?             no
    (The GNU allocators don't work with this system configuration.)
  Should Emacs use a relocating allocator for buffers?    no
  Should Emacs use mmap(2) for buffer allocation?         yes
  What window system should Emacs use?                    w32
  What toolkit should Emacs use?                          none
  Where do we find X Windows header files?                NONE
  Where do we find X Windows libraries?                   NONE
  Does Emacs use -lXaw3d?                                 no
  Does Emacs use -lXpm?                                   yes
  Does Emacs use -ljpeg?                                  yes
  Does Emacs use -ltiff?                                  yes
  Does Emacs use a gif library?                           yes
  Does Emacs use a png library?                           yes
  Does Emacs use -lrsvg-2?                                yes
  Does Emacs use cairo?                                   no
  Does Emacs use -llcms2?                                 yes
  Does Emacs use imagemagick?                             no
  Does Emacs use native APIs for images?                  yes (w32)
  Does Emacs support sound?                               yes
  Does Emacs use -lgpm?                                   no
  Does Emacs use -ldbus?                                  no
  Does Emacs use -lgconf?                                 no
  Does Emacs use GSettings?                               no
  Does Emacs use a file notification library?             yes (w32)
  Does Emacs use access control lists?                    yes
  Does Emacs use -lselinux?                               no
  Does Emacs use -lgnutls?                                yes
  Does Emacs use -lxml2?                                  yes
  Does Emacs use -lfreetype?                              no
  Does Emacs use HarfBuzz?                                yes
  Does Emacs use -lm17n-flt?                              no
  Does Emacs use -lotf?                                   no
  Does Emacs use -lxft?                                   no
  Does Emacs use -lsystemd?                               no
  Does Emacs use -ljansson?                               yes
  Does Emacs use the GMP library?                         yes
  Does Emacs directly use zlib?                           yes
  Does Emacs have dynamic modules support?                yes
  Does Emacs use toolkit scroll bars?                     yes
  Does Emacs support Xwidgets?                            no
  Does Emacs have threading support in lisp?              yes
  Does Emacs support the portable dumper?                 yes
  Does Emacs support legacy unexec dumping?               no
  Which dumping strategy does Emacs use?                  pdumper
  Does Emacs have native lisp compiler?                   no

Re: Current master doesn't build on Win10 (nor does emacs-28)

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Date: Sun, 24 Oct 2021 19:56:26 +0200
> Cc: emacs-devel@gnu.org
> 
> >> # 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.
> >
> > Note that this problem also occurs on emacs-28, and the workaround above
> > also works. Thus this needs a gnulib fix before the release.
> 
> I can't reproduce this for the emacs-28 branch with a pull from
> yesterday evening! It seems that
> 
> make bootstrap
> 
> make install
> 
> is running through without any errors.  The MSYS2 and MinGW collections
> are quite recent, but it seems gcc 11 is not installed.  gcc --version
> => 10.3.0

It only happens with GCC 11, that's why you don't see it.

Re: Current master doesn't build on Win10 (nor does emacs-28)

[H. Dieter Wilhelm]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
>> Date: Sun, 24 Oct 2021 19:56:26 +0200
>> Cc: emacs-devel@gnu.org
>> 
>> >> # 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.
>> >
>> > Note that this problem also occurs on emacs-28, and the workaround above
>> > also works. Thus this needs a gnulib fix before the release.
>> 
>> I can't reproduce this for the emacs-28 branch with a pull from
>> yesterday evening! It seems that
>> 
>> make bootstrap
>> 
>> make install
>> 
>> is running through without any errors.  The MSYS2 and MinGW collections
>> are quite recent, but it seems gcc 11 is not installed.  gcc --version
>> => 10.3.0
>
> It only happens with GCC 11, that's why you don't see it.

I see, thanks.  Is it possible to install both versions of gcc and the
necessary libraries?  (I've seen that when I would install
mingw-w64-x68_64-gcc the gcc 10.3.0 executable will be overwritten.)

Re: Current master doesn't build on Win10 (nor does emacs-28)

[Eli Zaretskii]

> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> Cc: andrewjmoreton@gmail.com,  emacs-devel@gnu.org
> Date: Sun, 24 Oct 2021 20:31:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: "H. Dieter Wilhelm" <dieter@duenenhof-wilhelm.de>
> >> Date: Sun, 24 Oct 2021 19:56:26 +0200
> >> Cc: emacs-devel@gnu.org
> >> 
> >> >> # 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.
> >> >
> >> > Note that this problem also occurs on emacs-28, and the workaround above
> >> > also works. Thus this needs a gnulib fix before the release.
> >> 
> >> I can't reproduce this for the emacs-28 branch with a pull from
> >> yesterday evening! It seems that
> >> 
> >> make bootstrap
> >> 
> >> make install
> >> 
> >> is running through without any errors.  The MSYS2 and MinGW collections
> >> are quite recent, but it seems gcc 11 is not installed.  gcc --version
> >> => 10.3.0
> >
> > It only happens with GCC 11, that's why you don't see it.
> 
> I see, thanks.  Is it possible to install both versions of gcc and the
> necessary libraries?

It's possible, but not necessarily easy.  You rename the original
gcc.exe to gcc10.exe, and all the rest should "just work" as long as
the MinGW installation doesn't remove the old version. (I have no idea
how to tell pacman not to do that, but maybe someone else here would
know.)  You then invoke GCC 10 as "gcc10" instead of "gcc" (so you
should reconfigure Emacs to use that when compiling).

But I think all of this should now be unnecessary, since fixes have
been installed on both branches.