emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs build fails on Windows mingw64


From: Paul Eggert
Subject: Re: Emacs build fails on Windows mingw64
Date: Sun, 24 Oct 2021 13:05:32 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

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.




reply via email to

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