bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs build fails on Windows mingw64


From: Andy Moreton
Subject: Re: Emacs build fails on Windows mingw64
Date: Mon, 25 Oct 2021 22:26:25 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (windows-nt)

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]