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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 72335 in the body.
You can then email your comments to 72335 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "YI Yue" <include_yy <at> qq.com>
To: "bug-gnu-emacs" <bug-gnu-emacs <at> gnu.org>
Subject: An attempt to fix UCRT64 build failure
Date: Sun, 28 Jul 2024 22:55:48 +0900

[Message part 1 (text/plain, inline)]

Hello, everyone

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:

./temacs --batch  -l loadup --temacs=pbootstrap \
        --bin-dest '/d/user/yy/emacs-build/bin/' --eln-dest '/d/user/yy/emacs-build/lib/emacs/31.0.50/'
D:\user\yy\emacs-master\src\temacs.exe: Write error to standard output: No such file or directory

MSYS2 do provides a patch[2] that do something about function
`close_output_streams' in src/sysdep.c. By applying it, I can get these results:

***
*** "make all" succeeded, but Emacs is not functional.
***

Sometimes I'll check emacs-devel to see if there are any progress in solving
this problem, such as this[3]. Two days ago I saw Pip Cet's "MPS: Win64
testers?"[4] and it inspired me that the problem may come from `init_ntproc' in
src/w32.c. After seeing UCRT's documentation[5], I think maybe we can use
`_fcloseall' instead of `fclose'? By using this, I get no error above when building 
in MSYS2/UCRT64.

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

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

[ucrt.patch (application/octet-stream, attachment)]

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
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 17:29:49 +0300

tags 72335 wontfix
thanks

> Date: Sun, 28 Jul 2024 22:55:48 +0900
> From:  "YI Yue" via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> 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:
> 
> ./temacs --batch  -l loadup --temacs=pbootstrap \
>         --bin-dest '/d/user/yy/emacs-build/bin/' --eln-dest '/d/user/yy/emacs-build/lib/emacs/31.0.50/'
> D:\user\yy\emacs-master\src\temacs.exe: Write error to standard output: No such file or directory

The UCRT build of Emacs on MS-Windows is not officially supported.
And it will remain unsupported until some volunteer steps forward to
take the responsibility for testing, maintaining, and developing Emacs
on Windows when linked with UCRT.  I asked several times for such a
volunteer, but no one picked up the gauntlet.

The first job of such a volunteer, if and when he or she steps up,
will be to solve this and a couple of other problems which were
reported lately for this build.  Until now, the attempts to understand
why close_stream fails for the standard streams in the UCRT build were
unsuccessful, unfortunately, even though these attempts included the
study of the UCRT sources that are available on the Internet.

> MSYS2 do provides a patch[2] that do something about function
> `close_output_streams' in src/sysdep.c. By applying it, I can get these results:
> 
> ***
> *** "make all" succeeded, but Emacs is not functional.
> ***

Those patches are ad-hoc and come without a satisfactory explanation
of their reason(s).  Being able to make sure the standard streams are
successfully closed is important, so I don't want to disable that in
the upstream sources.  Emacs is Free Software, so people can always
apply those patches to their local builds if they must use the UCRT
build and if they don't care about stdout/stderr.

> Sometimes I'll check emacs-devel to see if there are any progress in solving
> this problem, such as this[3]. Two days ago I saw Pip Cet's "MPS: Win64
> testers?"[4] and it inspired me that the problem may come from `init_ntproc' in
> src/w32.c. After seeing UCRT's documentation[5], 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 is what we need: according to the MS
documentation, it closes all the streams _except_ the standard ones,
so it's the exact opposite of what we need.

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

From: "o0o0oºÄ×Ó" <include_yy <at> qq.com>
To: "72335" <72335 <at> debbugs.gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>
Subject: »Ø¸´£º bug#72335: An attempt to fix UCRT64 build failure
Date: Sun, 28 Jul 2024 23:47:13 +0900

> The first job of such a volunteer, if and when he or she steps up,
> will be to solve this and a couple of other problems which were
> reported lately for this build.  Until now, the attempts to understand
> why close_stream fails for the standard streams in the UCRT build were
> unsuccessful, unfortunately, even though these attempts included the
> study of the UCRT sources that are available on the Internet.

> I don't think _fcloseall is what we need: according to the MS
> documentation, it closes all the streams _except_ the standard ones,
> so it's the exact opposite of what we need.

I understand.

Thank you for your patience, Eli. Maybe I'll do some research on UCRT port for
Emacs one day.

Regards.

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

From: "o0o0oºÄ×Ó" <include_yy <at> qq.com>
To: "72335" <72335 <at> debbugs.gnu.org>
Cc: Pip Cet <pipcet <at> protonmail.com>
Subject: »Ø¸´£º bug#72335: An attempt to fix UCRT64 build failure
Date: Sun, 28 Jul 2024 23:49:37 +0900

> Just to confirm, that's on native Windows, right?

Yes, but as Eli said, my approach is not right, so just ignore it.
Sorry for wasting some time.

Regards.2

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

From: Angelo Graziosi <angelo.g0 <at> libero.it>
To: include_yy <at> qq.com
Cc: 72335 <at> debbugs.gnu.org
Subject: Re: bug#72335: An attempt to fix UCRT64 build failure
Date: Sat, 3 Aug 2024 17:39:10 +0200

> MSYS2 do provides a patch[2] that do something about function
> `close_output_streams' in src/sysdep.c. By applying it, I can get these results:
> 
> ***
> *** "make all" succeeded, but Emacs is not functional.
> ***
This happens if you apply only one patch.

You have to apply _both_ patches (don't ask WHY!):

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/001-ucrt.patch

https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/002-clang-fixes.patch

I do monthly UCRT64 builds of Emacs master on Win10 (*true* machine, not 
Wine nor VBox). I did the last build with yesterday master and had only 
two warnings for ORG/TEXI files

org.texi:16157: warning: @anchor should not appear on @item line
org.texi:16170: warning: @anchor should not appear on @item line

Maybe MSYS2 people which created those patches can clarify...

Ciao,
  Angelo.

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

From: "Yi Yue" <include_yy <at> qq.com>
To: "Angelo Graziosi" <angelo.g0 <at> libero.it>
Cc: 72335 <72335 <at> debbugs.gnu.org>
Subject: Re: bug#72335: An attempt to fix UCRT64 build failure
Date: Mon, 12 Aug 2024 01:50:21 +0900

> This happens if you apply only one patch.

> You have to apply _both_ patches (don't ask WHY!):

> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/001-ucrt.patch

> https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/002-clang-fixes.patch

> I do monthly UCRT64 builds of Emacs master on Win10 (*true* machine, not Wine nor VBox). I did the last build with yesterday master and had only two warnings for ORG/TEXI filesorg.texi:16157: warning: @anchor should not appear on @item line
> org.texi:16170: warning: @anchor should not appear on @item line

> Maybe MSYS2 people which created those patches can clarify...

> Ciao,
>   Angelo.

Hi Angelo, Thanks for your advice, I didn't reply to you because I have seen it in your reply in Emacs-devel.

Now, the UCRT problem seems solved by Quang Kien Nguyen[1], I tried the last master branch and compiled it in UCRT64 environment, it succeeds.

Also, you don't need to reply to me, since this bug report is of little use.

Regards

Yi Yue
[1] https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00192.html

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

From: Angelo Graziosi <angelo.g0 <at> libero.it>
To: Yi Yue <include_yy <at> qq.com>
Cc: 72335 <72335 <at> debbugs.gnu.org>
Subject: Re: bug#72335: An attempt to fix UCRT64 build failure
Date: Sun, 11 Aug 2024 20:35:54 +0200

Il 11/08/2024 18:50, Yi Yue ha scritto:
> > This happens if you apply only one patch.
> 
> > You have to apply _both_ patches (don't ask WHY!):
> 
> > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/001-ucrt.patch
> 
> > https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/002-clang-fixes.patch
> 
> > I do monthly UCRT64 builds of Emacs master on Win10 (*true* machine, not Wine nor VBox). I did the last build with yesterday master and had only two warnings for ORG/TEXI filesorg.texi:16157: warning: @anchor should not appear on @item line
> > org.texi:16170: warning: @anchor should not appear on @item line
> 
> > Maybe MSYS2 people which created those patches can clarify...
> 
> > Ciao,
> >   Angelo.
> 
> Hi Angelo, Thanks for your advice, I didn't reply to you because I have seen it in your reply in Emacs-devel.
> 
> Now, the UCRT problem seems solved by Quang Kien Nguyen[1], I tried the last master branch and compiled it in UCRT64 environment, it succeeds.
> 
> Also, you don't need to reply to me, since this bug report is of little use.

Yes I know. I have built with Quang patch last week and have verified 
that now Emacs builds from master OB in MSYS2/UCRT64. Maybe we have to 
inform MSYS2 people...

Many tanks to Quang and Eli!

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 72335-done <at> debbugs.gnu.org, YI Yue <include_yy <at> qq.com>
Subject: Re: bug#72335: An attempt to fix UCRT64 build failure
Date: Mon, 10 Feb 2025 23:34:17 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 72335 wontfix
> thanks
>
>> Date: Sun, 28 Jul 2024 22:55:48 +0900
>> From:  "YI Yue" via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> 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:
>>
>> ./temacs --batch  -l loadup --temacs=pbootstrap \
>>         --bin-dest '/d/user/yy/emacs-build/bin/' --eln-dest '/d/user/yy/emacs-build/lib/emacs/31.0.50/'
>> D:\user\yy\emacs-master\src\temacs.exe: Write error to standard output: No such file or directory
>
> The UCRT build of Emacs on MS-Windows is not officially supported.
> And it will remain unsupported until some volunteer steps forward to
> take the responsibility for testing, maintaining, and developing Emacs
> on Windows when linked with UCRT.  I asked several times for such a
> volunteer, but no one picked up the gauntlet.

I'm therefore closing this bug report.

Previous Next

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