all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#72335: An attempt to fix UCRT64 build failure
@ 2024-07-28 13:55 YI Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-07-28 14:22 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: YI Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-28 13:55 UTC (permalink / raw)
  To: 72335

[-- 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);

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* bug#72335: An attempt to fix UCRT64 build failure
  2024-07-28 13:55 bug#72335: An attempt to fix UCRT64 build failure YI Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-07-28 14:22 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-07-28 14:49   ` bug#72335: ��� " o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-07-28 14:29 ` Eli Zaretskii
  2024-08-03 15:39 ` Angelo Graziosi
  2 siblings, 1 reply; 8+ messages in thread
From: Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-28 14:22 UTC (permalink / raw)
  To: YI Yue; +Cc: 72335

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#72335: An attempt to fix UCRT64 build failure
  2024-07-28 13:55 bug#72335: An attempt to fix UCRT64 build failure YI Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-07-28 14:22 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-07-28 14:29 ` Eli Zaretskii
  2024-07-28 14:47   ` bug#72335: ��� " o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-03 15:39 ` Angelo Graziosi
  2 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2024-07-28 14:29 UTC (permalink / raw)
  To: YI Yue; +Cc: 72335

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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#72335: ��� bug#72335: An attempt to fix UCRT64 build failure
  2024-07-28 14:29 ` Eli Zaretskii
@ 2024-07-28 14:47   ` o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 8+ messages in thread
From: o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-28 14:47 UTC (permalink / raw)
  To: 72335; +Cc: Eli Zaretskii

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

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

&gt; I don't think _fcloseall is what we need: according to the MS
&gt; documentation, it closes all the streams _except_ the standard ones,
&gt; 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#72335: ��� bug#72335: An attempt to fix UCRT64 build failure
  2024-07-28 14:22 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-07-28 14:49   ` o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 8+ messages in thread
From: o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-07-28 14:49 UTC (permalink / raw)
  To: 72335; +Cc: Pip Cet

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

&gt; 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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#72335: An attempt to fix UCRT64 build failure
  2024-07-28 13:55 bug#72335: An attempt to fix UCRT64 build failure YI Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-07-28 14:22 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-07-28 14:29 ` Eli Zaretskii
@ 2024-08-03 15:39 ` Angelo Graziosi
  2024-08-11 16:50   ` Yi Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2 siblings, 1 reply; 8+ messages in thread
From: Angelo Graziosi @ 2024-08-03 15:39 UTC (permalink / raw)
  To: include_yy; +Cc: 72335

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#72335: An attempt to fix UCRT64 build failure
  2024-08-03 15:39 ` Angelo Graziosi
@ 2024-08-11 16:50   ` Yi Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2024-08-11 18:35     ` Angelo Graziosi
  0 siblings, 1 reply; 8+ messages in thread
From: Yi Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-08-11 16:50 UTC (permalink / raw)
  To: Angelo Graziosi; +Cc: 72335

&gt; This happens if you apply only one patch.

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

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

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

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

&gt; Maybe MSYS2 people which created those patches can clarify...

&gt; Ciao,
&gt;   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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#72335: An attempt to fix UCRT64 build failure
  2024-08-11 16:50   ` Yi Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2024-08-11 18:35     ` Angelo Graziosi
  0 siblings, 0 replies; 8+ messages in thread
From: Angelo Graziosi @ 2024-08-11 18:35 UTC (permalink / raw)
  To: Yi Yue; +Cc: 72335



Il 11/08/2024 18:50, Yi Yue ha scritto:
> &gt; This happens if you apply only one patch.
> 
> &gt; You have to apply _both_ patches (don't ask WHY!):
> 
> &gt; https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/001-ucrt.patch
> 
> &gt; https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-emacs/002-clang-fixes.patch
> 
> &gt; I do monthly UCRT64 builds of Emacs master on Win10 (*true* machine, not&nbsp;Wine nor VBox). I did the last build with yesterday master and had only&nbsp;two warnings for ORG/TEXI filesorg.texi:16157: warning: @anchor should not appear on @item line
> &gt; org.texi:16170: warning: @anchor should not appear on @item line
> 
> &gt; Maybe MSYS2 people which created those patches can clarify...
> 
> &gt; Ciao,
> &gt;   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!





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-08-11 18:35 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-28 13:55 bug#72335: An attempt to fix UCRT64 build failure YI Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-28 14:22 ` Pip Cet via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-28 14:49   ` bug#72335: ��� " o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-07-28 14:29 ` Eli Zaretskii
2024-07-28 14:47   ` bug#72335: ��� " o0o0o���� via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-03 15:39 ` Angelo Graziosi
2024-08-11 16:50   ` Yi Yue via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-08-11 18:35     ` Angelo Graziosi

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.