Re: Emacs build fails on Windows mingw64

Re: Emacs build fails on Windows mingw64

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 391 bytes --]

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.


[-- Attachment #2: 0001-Include-config.h-first-in-MS-Windows-source.patch --]
[-- Type: text/x-patch, Size: 2575 bytes --]

From 7bb574b48c7c8be0eb1e941c6da048cfb509cdff Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 23 Oct 2021 20:35:18 -0700
Subject: [PATCH] Include <config.h> first in MS-Windows source

---
 lib-src/ntlib.c | 2 ++
 nt/addpm.c      | 3 +++
 nt/cmdproxy.c   | 2 ++
 nt/ddeclient.c  | 2 ++
 nt/preprep.c    | 2 ++
 nt/runemacs.c   | 2 ++
 6 files changed, 13 insertions(+)

diff --git a/lib-src/ntlib.c b/lib-src/ntlib.c
index bcbc006431..e011de5b91 100644
--- a/lib-src/ntlib.c
+++ b/lib-src/ntlib.c
@@ -20,6 +20,8 @@ Copyright (C) 1994, 2001-2021 Free Software Foundation, Inc.
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
+#include <config.h>
+
 #include <windows.h>
 #include <stdlib.h>
 #include <stdio.h>
diff --git a/nt/addpm.c b/nt/addpm.c
index f54a6ea9f7..4ec372ccfe 100644
--- a/nt/addpm.c
+++ b/nt/addpm.c
@@ -34,6 +34,9 @@
    installed, then the DDE fallback for creating icons the Windows 3.1
    progman way will be used instead, but that is prone to lockups
    caused by other applications not servicing their message queues.  */
+
+#include <config.h>
+
 #include <stdlib.h>
 #include <stdio.h>
 #include <malloc.h>
diff --git a/nt/cmdproxy.c b/nt/cmdproxy.c
index 224f68b1e8..505855318d 100644
--- a/nt/cmdproxy.c
+++ b/nt/cmdproxy.c
@@ -27,6 +27,8 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
+#include <config.h>
+
 #include <windows.h>
 
 #include <stdarg.h>  /* va_args */
diff --git a/nt/ddeclient.c b/nt/ddeclient.c
index c577bfcfa9..1390c334b7 100644
--- a/nt/ddeclient.c
+++ b/nt/ddeclient.c
@@ -16,6 +16,8 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
+#include <config.h>
+
 #include <windows.h>
 #include <ddeml.h>
 #include <stdlib.h>
diff --git a/nt/preprep.c b/nt/preprep.c
index 78ed1c3238..b73d3bb9fa 100644
--- a/nt/preprep.c
+++ b/nt/preprep.c
@@ -21,6 +21,8 @@
      based on code from addsection.c
 */
 
+#include <config.h>
+
 #include <stdlib.h>
 #include <stdio.h>
 #include <fcntl.h>
diff --git a/nt/runemacs.c b/nt/runemacs.c
index 308e856be2..f8f60b0665 100644
--- a/nt/runemacs.c
+++ b/nt/runemacs.c
@@ -40,6 +40,8 @@ Copyright (C) 2001-2021 Free Software Foundation, Inc.
 
 /* #define CHOOSE_NEWEST_EXE */
 
+#include <config.h>
+
 #include <windows.h>
 #include <string.h>
 #include <malloc.h>
-- 
2.31.1

Re: Emacs build fails on Windows mingw64

[Eli Zaretskii]

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

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?

Re: Emacs build fails on Windows mingw64

[Andy Moreton]

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

Re: Emacs build fails on Windows mingw64

[Paul Eggert]

[-- Attachment #1: Type: text/plain, Size: 849 bytes --]

On 10/24/21 2:26 AM, Eli Zaretskii wrote:
> 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?

It's so that apps can be checked better statically. For example, the 
contrived code:

    return strcmp (x, strdup (x));

getts a diagnostic about a memory leak. This can be helpful regardless 
of whether Gnulib's strdup substitute code is used.

The Gnulib wrapper here is merely mimicking what glibc does; it's not a 
Gnulib invention.


> ntlib cannot include config.h,
> due to various redefinitions and redirections we do in ms-w32.h for
> Emacs.

I now see Emacs has a symbol DEFER_MS_W3_H to deal with this glitch. So 
how about the attached patch instead? If it doesn't suffice, presumably 
something like DEFER_MS_W3_H would suffice.


[-- Attachment #2: 0001-Include-config.h-first-in-MS-Windows-source.patch --]
[-- Type: text/x-patch, Size: 2720 bytes --]

From 878c4c0d20bb94d9af8cb4161b1a7cbf73c7ba90 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 23 Oct 2021 20:35:18 -0700
Subject: [PATCH] Include <config.h> first in MS-Windows source

---
 lib-src/ntlib.c | 3 +++
 nt/addpm.c      | 4 ++++
 nt/cmdproxy.c   | 3 +++
 nt/ddeclient.c  | 3 +++
 nt/preprep.c    | 3 +++
 nt/runemacs.c   | 3 +++
 6 files changed, 19 insertions(+)

diff --git a/lib-src/ntlib.c b/lib-src/ntlib.c
index bcbc006431..f1c68cb1b2 100644
--- a/lib-src/ntlib.c
+++ b/lib-src/ntlib.c
@@ -20,6 +20,9 @@ Copyright (C) 1994, 2001-2021 Free Software Foundation, Inc.
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
+#define DEFER_MS_W3_H
+#include <config.h>
+
 #include <windows.h>
 #include <stdlib.h>
 #include <stdio.h>
diff --git a/nt/addpm.c b/nt/addpm.c
index f54a6ea9f7..f07e4c2c5a 100644
--- a/nt/addpm.c
+++ b/nt/addpm.c
@@ -34,6 +34,10 @@
    installed, then the DDE fallback for creating icons the Windows 3.1
    progman way will be used instead, but that is prone to lockups
    caused by other applications not servicing their message queues.  */
+
+#define DEFER_MS_W3_H
+#include <config.h>
+
 #include <stdlib.h>
 #include <stdio.h>
 #include <malloc.h>
diff --git a/nt/cmdproxy.c b/nt/cmdproxy.c
index 224f68b1e8..2bc03673d5 100644
--- a/nt/cmdproxy.c
+++ b/nt/cmdproxy.c
@@ -27,6 +27,9 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
+#define DEFER_MS_W3_H
+#include <config.h>
+
 #include <windows.h>
 
 #include <stdarg.h>  /* va_args */
diff --git a/nt/ddeclient.c b/nt/ddeclient.c
index c577bfcfa9..1c1f7679ea 100644
--- a/nt/ddeclient.c
+++ b/nt/ddeclient.c
@@ -16,6 +16,9 @@
 You should have received a copy of the GNU General Public License
 along with GNU Emacs.  If not, see <https://www.gnu.org/licenses/>.  */
 
+#define DEFER_MS_W3_H
+#include <config.h>
+
 #include <windows.h>
 #include <ddeml.h>
 #include <stdlib.h>
diff --git a/nt/preprep.c b/nt/preprep.c
index 78ed1c3238..48c55ef221 100644
--- a/nt/preprep.c
+++ b/nt/preprep.c
@@ -21,6 +21,9 @@
      based on code from addsection.c
 */
 
+#define DEFER_MS_W3_H
+#include <config.h>
+
 #include <stdlib.h>
 #include <stdio.h>
 #include <fcntl.h>
diff --git a/nt/runemacs.c b/nt/runemacs.c
index 308e856be2..cce4904d88 100644
--- a/nt/runemacs.c
+++ b/nt/runemacs.c
@@ -40,6 +40,9 @@ Copyright (C) 2001-2021 Free Software Foundation, Inc.
 
 /* #define CHOOSE_NEWEST_EXE */
 
+#define DEFER_MS_W3_H
+#include <config.h>
+
 #include <windows.h>
 #include <string.h>
 #include <malloc.h>
-- 
2.31.1

Re: Emacs build fails on Windows mingw64

[Paul Eggert]

On 10/24/21 6:50 AM, Andy Moreton wrote:
> 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

Although that works around this particular problem, it is vulnerable to 
future changes in Gnulib that add more such macros, and it's likely 
other Emacs source files would need similar workarounds in the future 
(or perhaps even now, in slightly-different MS-Windows configurations? I 
have no clue about the MS-Windows side).

Re: Emacs build fails on Windows mingw64

[Eli Zaretskii]

> Cc: andrewjmoreton@gmail.com, bug-gnulib@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 24 Oct 2021 08:25:29 -0400
> 
> > ntlib cannot include config.h,
> > due to various redefinitions and redirections we do in ms-w32.h for
> > Emacs.
> 
> I now see Emacs has a symbol DEFER_MS_W3_H to deal with this glitch. So 
> how about the attached patch instead? If it doesn't suffice, presumably 
> something like DEFER_MS_W3_H would suffice.

We could try all that, but not on the release branch.  There, I'd like
a simple and safe fix.  Is such a thing possible?

Can you explain why config.h is needed there, and why only for GCC 11?

Thanks.

Re: Emacs build fails on Windows mingw64

[Paul Eggert]

On 10/24/21 9:58 AM, Eli Zaretskii wrote:
> We could try all that, but not on the release branch.  There, I'd like
> a simple and safe fix.  Is such a thing possible?

Andy suggested a simple fix that I quoted here:

https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html

We could apply that patch just to ntlib.c and just in emacs-28 (do not 
merge to master) as Andy says that works for him; and we could then 
apply the more-systematic patch of 
<https://lists.gnu.org/r/emacs-devel/2021-10/msg01697.html> to master. 
Andy's patch is definitely safe for GNU and POSIXish hosts. I don't know 
whether it suffices for all MS-Windows platforms and Emacs builds.


> Can you explain why config.h is needed there, and why only for GCC 11?
config.h is needed because it defines macros used by lib/string.h and 
other lib/*.h files that come from Gnulib. I don't know why the problem 
occurs only for GCC 11 on MS-Windows platforms, as I would think it'd 
also occur with earlier GCC versions. Older GCC versions don't do the 
static checking I mentioned, so the macros do not help checking with 
older GCC. The macros can safely be #defined to empty as Andy's patch 
suggested, so long as config.h isn't included (as it would define them 
differently). The downsides of Andy's approach (as compared to the 
more-systematic patch) is that you lose out some static checking with 
recent GCC, and I worry (without really knowing) that similar problems 
may lurk in other MS-Windows-specific .c files on some other MS-Windows 
platforms.

Re: Emacs build fails on Windows mingw64

[Eli Zaretskii]

> Cc: andrewjmoreton@gmail.com, bug-gnulib@gnu.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 24 Oct 2021 13:05:32 -0400
> 
> On 10/24/21 9:58 AM, Eli Zaretskii wrote:
> > We could try all that, but not on the release branch.  There, I'd like
> > a simple and safe fix.  Is such a thing possible?
> 
> Andy suggested a simple fix that I quoted here:
> 
> https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html
> 
> We could apply that patch just to ntlib.c and just in emacs-28 (do not 
> merge to master) as Andy says that works for him; and we could then 
> apply the more-systematic patch of 
> <https://lists.gnu.org/r/emacs-devel/2021-10/msg01697.html> to master. 
> Andy's patch is definitely safe for GNU and POSIXish hosts. I don't know 
> whether it suffices for all MS-Windows platforms and Emacs builds.

Done on both counts, let's hope the problems go away now.

Thanks.

Re: Emacs build fails on Windows mingw64

[Andy Moreton]

On Sun 24 Oct 2021, Paul Eggert wrote:

> On 10/24/21 9:58 AM, Eli Zaretskii wrote:
>> We could try all that, but not on the release branch.  There, I'd like
>> a simple and safe fix.  Is such a thing possible?
>
> Andy suggested a simple fix that I quoted here:
>
> https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html
>
> We could apply that patch just to ntlib.c and just in emacs-28 (do not merge
> to master) as Andy says that works for him;

Yes, that minimal fix bootstraps on emacs-28 and master with 64bit mingw64.

> and we could then apply the more-systematic patch of
> <https://lists.gnu.org/r/emacs-devel/2021-10/msg01697.html> to master. Andy's
> patch is definitely safe for GNU and POSIXish hosts. I don't know whether it
> suffices for all MS-Windows platforms and Emacs builds.

The patch still needs some work:
a) The symbol in conf_post.h is DEFER_MS_W32_H (not DEFER_MS_W3_H),
   so needs fixing in the patch.
b) BASE_CFLAGS in nt/Makefile.in needs changes to match the include
   switches in lib-src/Makefile.in (so that config.h, conf_post.h 
   and attribute.h etc can be found).

After fixing those minor issues, emacs-28 bootstraps with only one
additional warning due to the patch:

  C:/emacs/git/emacs/emacs-28/lib-src/ntlib.c:294: warning: "IS_DIRECTORY_SEP" redefined
    294 | #define IS_DIRECTORY_SEP(x) ((x) == '/' || (x) == '\\')
        |
  In file included from C:/emacs/git/emacs/emacs-28/lib-src/ntlib.c:24:
  ../src/config.h:1563: note: this is the location of the previous definition
   1563 | #define IS_DIRECTORY_SEP(_c_) ((_c_) == '/' || (_c_) == '\\')
        |

(There are a few other new warnings in the build with either approach,
probably due to additional checks that have appeared after upgrading from
gcc 10.3 to gcc 11.2.)

I understand Eli's desire to avoid using this patch on emacs-28 as the
changes are potentially destabilising this late in the release cycle.

>> Can you explain why config.h is needed there, and why only for GCC 11?
> config.h is needed because it defines macros used by lib/string.h and other
> lib/*.h files that come from Gnulib. I don't know why the problem occurs only
> for GCC 11 on MS-Windows platforms, as I would think it'd also occur with
> earlier GCC versions. Older GCC versions don't do the static checking I
> mentioned, so the macros do not help checking with older GCC. The macros can
> safely be #defined to empty as Andy's patch suggested, so long as config.h
> isn't included (as it would define them differently). The downsides of Andy's
> approach (as compared to the more-systematic patch) is that you lose out some
> static checking with recent GCC, and I worry (without really knowing) that
> similar problems may lurk in other MS-Windows-specific .c files on some other
> MS-Windows platforms.

My suggestion to define the macros was a minimal workaround to get
emacs building again for me until proper fix could be developed.

I suspect the issue has been in the gnulib header for some time, but has
only been triggered in the build after upgrading to gcc >=11 as
otherwise the relevant code is not built (it is guarded with a gcc
version check).

    AndyM

Re: Emacs build fails on Windows mingw64

[Óscar Fuentes]

Paul Eggert <eggert@cs.ucla.edu> writes:

> I don't know why the
> problem occurs only for GCC 11 on MS-Windows platforms, as I would
> think it'd also occur with earlier GCC versions.

Most likely the problem is caused by an CRT update, not by gcc 11.

Re: Emacs build fails on Windows mingw64

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sun, 24 Oct 2021 20:01:06 +0200
> Cc: bug-gnulib@gnu.org
> 
> Paul Eggert <eggert@cs.ucla.edu> writes:
> 
> > I don't know why the
> > problem occurs only for GCC 11 on MS-Windows platforms, as I would
> > think it'd also occur with earlier GCC versions.
> 
> Most likely the problem is caused by an CRT update, not by gcc 11.

Could be, but unlikely: the problematic condition is only enabled for
GCC 11.

Re: Emacs build fails on Windows mingw64

[Bruno Haible]

Andy Moreton wrote:
> > Andy suggested a simple fix that I quoted here:
> >
> > https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html
> >
> > We could apply that patch just to ntlib.c and just in emacs-28 (do not merge
> > to master) as Andy says that works for him;
> 
> Yes, that minimal fix bootstraps on emacs-28 and master with 64bit mingw64.

Thanks for the confirmation that the lack of definitions of
_GL_ATTRIBUTE_MALLOC and _GL_ATTRIBUTE_DEALLOC_FREE was indeed the problem.

Although Paul is right in saying that every file that uses Gnulib needs to
<config.h>, we make compromises regarding this requirement for the *.in.h
files. The commit
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=354f27fea9bd4ecb53980de6bd374434a204afc5
from 2021-08-22 "Make generated .in.h files as standalone as possible"
added definitions of _GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
_GL_ATTRIBUTE_MALLOC to stdlib.h, and assumed that these definitions would
also be visible in string.h, since string.h did a '#include <stdlib.h>'.

The commit
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=a4a2d039a9117266ed8cb1977241e7c34b368993
from 2021-09-07 then removed this '#include <stdlib.h>' from string.in.h.
As a compensation, it added the declaration of free/rpl_free. But it needs
also the macros _GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
_GL_ATTRIBUTE_MALLOC — when <config.h> is not pre-included.

The issue was also reported to me in private mail by Jan Engelhardt,
regarding the 'cdecl' package, on 2021-09-28, but I didn't have time
to react then; sorry about that.

This patch should fix it.


2021-10-24  Bruno Haible  <bruno@clisp.org>

	string: Avoid syntax error re strdup in string.in.h (regr. 2021-09-07).
	Reported by Jan Engelhardt <jengelh@inai.de>
	and by Arash Esbati <arash@gnu.org> via Andy Moreton in
	<https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00058.html>.
	* lib/string.in.h (_GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
	_GL_ATTRIBUTE_MALLOC): Add fallback declarations, like in
	lib/stdlib.in.h.
	* lib/wchar.in.h (_GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
	_GL_ATTRIBUTE_MALLOC): Likewise.

diff --git a/lib/string.in.h b/lib/string.in.h
index 8d77ae380..afe735086 100644
--- a/lib/string.in.h
+++ b/lib/string.in.h
@@ -67,6 +67,35 @@
 # include <strings.h>
 #endif
 
+/* _GL_ATTRIBUTE_DEALLOC (F, I) declares that the function returns pointers
+   that can be freed by passing them as the Ith argument to the
+   function F.  */
+#ifndef _GL_ATTRIBUTE_DEALLOC
+# if __GNUC__ >= 11
+#  define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i)))
+# else
+#  define _GL_ATTRIBUTE_DEALLOC(f, i)
+# endif
+#endif
+
+/* _GL_ATTRIBUTE_DEALLOC_FREE declares that the function returns pointers that
+   can be freed via 'free'; it can be used only after declaring 'free'.  */
+/* Applies to: functions.  Cannot be used on inline functions.  */
+#ifndef _GL_ATTRIBUTE_DEALLOC_FREE
+# define _GL_ATTRIBUTE_DEALLOC_FREE _GL_ATTRIBUTE_DEALLOC (free, 1)
+#endif
+
+/* _GL_ATTRIBUTE_MALLOC declares that the function returns a pointer to freshly
+   allocated memory.  */
+/* Applies to: functions.  */
+#ifndef _GL_ATTRIBUTE_MALLOC
+# if __GNUC__ >= 3 || defined __clang__
+#  define _GL_ATTRIBUTE_MALLOC __attribute__ ((__malloc__))
+# else
+#  define _GL_ATTRIBUTE_MALLOC
+# endif
+#endif
+
 /* The __attribute__ feature is available in gcc versions 2.5 and later.
    The attribute __pure__ was added in gcc 2.96.  */
 #ifndef _GL_ATTRIBUTE_PURE
diff --git a/lib/wchar.in.h b/lib/wchar.in.h
index f13379ad8..20315dd7b 100644
--- a/lib/wchar.in.h
+++ b/lib/wchar.in.h
@@ -84,6 +84,35 @@
 #ifndef _@GUARD_PREFIX@_WCHAR_H
 #define _@GUARD_PREFIX@_WCHAR_H
 
+/* _GL_ATTRIBUTE_DEALLOC (F, I) declares that the function returns pointers
+   that can be freed by passing them as the Ith argument to the
+   function F.  */
+#ifndef _GL_ATTRIBUTE_DEALLOC
+# if __GNUC__ >= 11
+#  define _GL_ATTRIBUTE_DEALLOC(f, i) __attribute__ ((__malloc__ (f, i)))
+# else
+#  define _GL_ATTRIBUTE_DEALLOC(f, i)
+# endif
+#endif
+
+/* _GL_ATTRIBUTE_DEALLOC_FREE declares that the function returns pointers that
+   can be freed via 'free'; it can be used only after declaring 'free'.  */
+/* Applies to: functions.  Cannot be used on inline functions.  */
+#ifndef _GL_ATTRIBUTE_DEALLOC_FREE
+# define _GL_ATTRIBUTE_DEALLOC_FREE _GL_ATTRIBUTE_DEALLOC (free, 1)
+#endif
+
+/* _GL_ATTRIBUTE_MALLOC declares that the function returns a pointer to freshly
+   allocated memory.  */
+/* Applies to: functions.  */
+#ifndef _GL_ATTRIBUTE_MALLOC
+# if __GNUC__ >= 3 || defined __clang__
+#  define _GL_ATTRIBUTE_MALLOC __attribute__ ((__malloc__))
+# else
+#  define _GL_ATTRIBUTE_MALLOC
+# endif
+#endif
+
 /* The __attribute__ feature is available in gcc versions 2.5 and later.
    The attribute __pure__ was added in gcc 2.96.  */
 #ifndef _GL_ATTRIBUTE_PURE

Re: Emacs build fails on Windows mingw64

[Eli Zaretskii]

> From: Bruno Haible <bruno@clisp.org>
> Date: Mon, 25 Oct 2021 00:52:45 +0200
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> 
> This patch should fix it.
> 
> 
> 2021-10-24  Bruno Haible  <bruno@clisp.org>
> 
> 	string: Avoid syntax error re strdup in string.in.h (regr. 2021-09-07).
> 	Reported by Jan Engelhardt <jengelh@inai.de>
> 	and by Arash Esbati <arash@gnu.org> via Andy Moreton in
> 	<https://lists.gnu.org/archive/html/bug-gnulib/2021-10/msg00058.html>.
> 	* lib/string.in.h (_GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
> 	_GL_ATTRIBUTE_MALLOC): Add fallback declarations, like in
> 	lib/stdlib.in.h.
> 	* lib/wchar.in.h (_GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
> 	_GL_ATTRIBUTE_MALLOC): Likewise.

Thanks, I guess we will see it soon on the Emacs master branch.

Re: Emacs build fails on Windows mingw64

[Andy Moreton]

On Mon 25 Oct 2021, Bruno Haible wrote:

> Andy Moreton wrote:
>> > Andy suggested a simple fix that I quoted here:
>> >
>> > https://lists.gnu.org/r/emacs-devel/2021-10/msg01698.html
>> >
>> > We could apply that patch just to ntlib.c and just in emacs-28 (do not merge
>> > to master) as Andy says that works for him;
>> 
>> Yes, that minimal fix bootstraps on emacs-28 and master with 64bit mingw64.
>
> Thanks for the confirmation that the lack of definitions of
> _GL_ATTRIBUTE_MALLOC and _GL_ATTRIBUTE_DEALLOC_FREE was indeed the problem.

Glad it was of some help: I was looking for a minimal workaround that would
allow the emacs release branch to build.

> Although Paul is right in saying that every file that uses Gnulib needs to
> <config.h>, we make compromises regarding this requirement for the *.in.h
> files. The commit
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=354f27fea9bd4ecb53980de6bd374434a204afc5
> from 2021-08-22 "Make generated .in.h files as standalone as possible"
> added definitions of _GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
> _GL_ATTRIBUTE_MALLOC to stdlib.h, and assumed that these definitions would
> also be visible in string.h, since string.h did a '#include <stdlib.h>'.
>
> The commit
> https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=a4a2d039a9117266ed8cb1977241e7c34b368993
> from 2021-09-07 then removed this '#include <stdlib.h>' from string.in.h.
> As a compensation, it added the declaration of free/rpl_free. But it needs
> also the macros _GL_ATTRIBUTE_DEALLOC, _GL_ATTRIBUTE_DEALLOC_FREE,
> _GL_ATTRIBUTE_MALLOC ― when <config.h> is not pre-included.
>
> The issue was also reported to me in private mail by Jan Engelhardt,
> regarding the 'cdecl' package, on 2021-09-28, but I didn't have time
> to react then; sorry about that.
>
> This patch should fix it.

Emacs now has patches to avoid this issue, but a gnulib fix to solve the
problem is also useful.

Thanks,

    AndyM