bug#72335: An attempt to fix UCRT64 build failure

bug#72335: An attempt to fix UCRT64 build failure

[YI Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

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

[-- Attachment #2: ucrt.patch --]
[-- Type: application/octet-stream, Size: 418 bytes --]

diff --git a/src/w32.c b/src/w32.c
index 31ffa301c2..a7fc0efde4 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -10513,9 +10513,13 @@ init_ntproc (int dumping)
 		     FALSE,
 		     DUPLICATE_SAME_ACCESS);

+#ifndef _UCRT
     fclose (stdin);
     fclose (stdout);
     fclose (stderr);
+#else
+    _fcloseall();
+#endif

     if (stdin_save != INVALID_HANDLE_VALUE)
       _open_osfhandle ((intptr_t) stdin_save, O_TEXT);

bug#72335: An attempt to fix UCRT64 build failure

[Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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@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

bug#72335: ��� bug#72335: An attempt to fix UCRT64 build failure

[o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 161 bytes --]

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

bug#72335: An attempt to fix UCRT64 build failure

[Eli Zaretskii]

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

bug#72335: ��� bug#72335: An attempt to fix UCRT64 build failure

[o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 744 bytes --]

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

bug#72335: An attempt to fix UCRT64 build failure

[Angelo Graziosi]

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

bug#72335: An attempt to fix UCRT64 build failure

[Yi Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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

bug#72335: An attempt to fix UCRT64 build failure

[Angelo Graziosi]

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!