From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?Q?=C3=93scar_Fuentes?= Newsgroups: gmane.emacs.devel Subject: Re: MinGW build on master fails with Error 127 Date: Sat, 24 Dec 2022 18:57:55 +0100 Message-ID: <878riw1y70.fsf@telefonica.net> References: <83wn6wr5oz.fsf@gnu.org> <0c9519c9-add7-9fb1-ac7f-2f20e1916d65@bluewin.ch> <83tu20r4y7.fsf@gnu.org> <01b7362d-7d60-3054-5590-d4dbbcda76d7@bluewin.ch> <83r0x4r490.fsf@gnu.org> <837cyh71ft.fsf@gnu.org> <832966a5-bd27-76f9-4757-a8c246eca416@bluewin.ch> <835ye06ex7.fsf@gnu.org> <87sfh424ya.fsf@telefonica.net> <83y1qw4x8w.fsf@gnu.org> <87o7rs22yn.fsf@telefonica.net> <83v8m04un9.fsf@gnu.org> <87cz8820hx.fsf@telefonica.net> <83sfh44t2t.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31845"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 24 18:58:45 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p98nF-00087z-7n for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Dec 2022 18:58:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p98mc-0003N0-4D; Sat, 24 Dec 2022 12:58:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p98ma-0003Ms-LD for emacs-devel@gnu.org; Sat, 24 Dec 2022 12:58:04 -0500 Original-Received: from relayout04-redir.e.movistar.es ([86.109.101.204]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p98mY-0007ra-K1; Sat, 24 Dec 2022 12:58:04 -0500 Original-Received: from sky (91.red-81-39-16.dynamicip.rima-tde.net [81.39.16.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: 981711563@telefonica.net) by relayout04.e.movistar.es (Postfix) with ESMTPSA id 4NfWx01gBmz116v; Sat, 24 Dec 2022 18:57:55 +0100 (CET) In-Reply-To: <83sfh44t2t.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Dec 2022 19:20:10 +0200") X-TnetOut-Country: IP: 81.39.16.91 | Country: ES X-TnetOut-Information: AntiSPAM and AntiVIRUS on relayout04 X-TnetOut-MsgID: 4NfWx01gBmz116v.A4510 X-TnetOut-SpamCheck: no es spam, clean X-TnetOut-From: ofv@wanadoo.es X-TnetOut-Watermark: 1672509476.62674@sozNTHFY4wSnMzgmmkk7gg Received-SPF: softfail client-ip=86.109.101.204; envelope-from=ofv@wanadoo.es; helo=relayout04-redir.e.movistar.es X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:301871 Archived-At: Eli Zaretskii writes: >> > And as long as I have your attention: what about the switch to UCRT64? >> > Does Emacs need something in its Makefile's to specify linking against >> > MSVCRT, even though UCRT64 is the default? The information at >> > >> > https://www.msys2.org/news/#2022-10-29-changing-the-default-environment-from-mingw64-to-ucrt64 >> > >> > doesn't provide any details about that. >> >> See >> >> https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-emacs > > There's nothing there regarding the runtime against which Emacs is > being linked. How does GCC/ld know which runtime to link against? Up > until now GCC would call the linker with the -lmsvcrt switch, so does > it now use some other switch? MSYS2 distributes multiple toolset/c-runtime combinations. Toolsets can be GNU (gcc, binutils, etc) or Clang, and c-runtime can be either mingw-w64 or UCRT. For a given combination the toolset is configured to work with a c-runtime, so it already knows what it needs to do the right thing. I guess it is possible to override the configuration of a toolset so to use a different c-runtime, but that's not something that MSYS2 encourage. > And what can users do to force MinGW64 to link against MSVCRT, if they > so wish? The MSYS2 distribution named "MINGW64" already links to MSVCRT, as always did, and that will not change. Is the UCRT64 distribution the one that provides a gcc/binutils/everything-else that links to UCRT. >> There is a patch specific for UCRT support. It's quite simple although >> the workaround for close_stream doesn't inspire confidence, hints that >> there might be subtle differences on the behavior of C runtime >> functions. > > It's a beginning of a very long journey, to learn about UCRT what > we've invested decades to learn about MSVCRT. AFAIK UCRT should work just fine (TM) as it is not an entirely new C Runtime, but a vastly updated version of MSVCRT with a new model of deployment for more robust versioning that allows incremental additions. I'm sure there are subtle differences and even some intended departure from behaviors that are deemed undesirable, though. My experience, both with my own projects and with the packages MSYS2 distributes, indicate that migrating to it is fairly painless, if noticeable at all. > And the patch indeed is not really acceptable, as it disables useful > behavior without a reasonable explanation. The commit message says "fclose fail during atexit as if they were already closed" but indeed it doesn't describe a user-visible problem. I can ask for more details, if you are interested. > Are the sources of UCRT available somewhere (as MSVCRT sources were)? They are distributed with Visual Studio. They are missing from a Community (the gratis version) install that I have around, but maybe I didn't check the option for installing them.