GNU bug report logs - #72335
An attempt to fix UCRT64 build failure

Previous Next

Full log

Message #8 received at 72335 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: YI Yue <include_yy <at> qq.com>
Cc: 72335 <at> debbugs.gnu.org
Subject: Re: bug#72335: An attempt to fix UCRT64 build failure
Date: Sun, 28 Jul 2024 14:22:25 +0000

On Sunday, July 28th, 2024 at 13:55, YI Yue" via "Bug reports for GNU Emacs, the Swiss army knife of text editors <bug-gnu-emacs <at> gnu.org> wrote:
> I occasionally try to compile Emacs to get the latest commits. But on Windows, I
> only use Mingw64 because it's the only one officially supported by Emacs.[1]
> When I try to build Emacs in MSYS2/UCRT64, I'll get these outputs:

Just to confirm, that's on native Windows, right? Because I don't know how UCRT behaves on that system, such information is greatly appreciated

> I think maybe we can use
> `_fcloseall' instead of` fclose'? By using this, I get no error above when building
> in MSYS2/UCRT64.

I don't think _fcloseall should have any effect on the standard three streams, so making the entire section "Initial preparation for subprocess support" should have the same effect, I think. That's what I'm doing in my ucrt64/msys2/wine experiments :-)

> I have little knowledge of MSVCRT and UCRT, it just works :)

Thanks, that's great to know.

> Here is my patch, regards.
> 
> [1]: https://lists.gnu.org/archive/html/help-gnu-emacs/2022-01/msg00441.html
> [2]: https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/001-ucrt.patch
> [3]: https://lists.gnu.org/archive/html/emacs-devel/2024-02/msg00744.html
> [4]: https://lists.gnu.org/archive/html/emacs-devel/2024-07/msg01055.html
> [5]: https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/fclose-fcloseall

Thanks again, particularly for going to the trouble of collecting those links.

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.