From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MinGW build on master fails with Error 127 Date: Sat, 24 Dec 2022 20:09:48 +0200 Message-ID: <83pmc84qs3.fsf@gnu.org> 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> <878riw1y70.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6506"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Dec 24 19:10:46 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 1p98yr-0001Un-LS for ged-emacs-devel@m.gmane-mx.org; Sat, 24 Dec 2022 19:10:46 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p98y1-0007KX-3S; Sat, 24 Dec 2022 13:09:53 -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 1p98xz-0007KH-4l for emacs-devel@gnu.org; Sat, 24 Dec 2022 13:09:51 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p98xy-0006Bo-Ic; Sat, 24 Dec 2022 13:09:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=YkDwrbTI+tA8cj4DJejYBUuhDr+iN2BswpFM7cIJj3k=; b=fKnS6soSKQFrIDklOOsV FI5pWhM5IFUjjGHFdSVuWg7+vfiv8qjzZ+8Bkvi385BjB2H849R2m4JxD8+lpBKhKRh6NnObmtxoe w8PBCuguQqCakmBN4aIu0J7R1sN//0UcqNMo4F9lKewVop5GmOHoAcJNU7c0AvAAhjZm7vuBH2Sow t8y63XluHbWvcamB7sULqzwhRsr/1OjVtkPViSPPB+lD1UbcXnMTNqI5TG9hu9hu615JktTpyEXPm wCojXCpsiNi2s2KUhfM8uze1PS/9u4sD4U7AGTBSL9RRDVGTzPwiMR7pcB7Le3E55md6/V8UyCfEe x9fyid9A6cojgg==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p98xx-0003g0-HY; Sat, 24 Dec 2022 13:09:50 -0500 In-Reply-To: <878riw1y70.fsf@telefonica.net> (message from =?iso-8859-1?Q?=D3scar?= Fuentes on Sat, 24 Dec 2022 18:57:55 +0100) 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:301873 Archived-At: > From: Óscar Fuentes > Cc: emacs-devel@gnu.org > Date: Sat, 24 Dec 2022 18:57:55 +0100 > > 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. So if the user has the UCRT version installed, they will necessarily link against UCRT64. Does the wording in nt/INSTALL.W64 guide users to only one of these two variants (and if so, to which one), or is it generic, and the user will have to choose when they install MinGW? > >> 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. Subtle differences do exist, as that patch demonstrates. Whether it will be painless for Emacs depends on how much of the sources of MSVCRT was inherited by UCRT. There are some quirks in MSVCRT that took us time to find out and accommodate for, and w32.c mentions that in several places. > 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. See above: Emacs is quite demanding in this regard, so I'm not as optimistic as you are, having spent enough hours reading the MSVCRT sources and documentation. > > 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. I am. And note that the MS documentation shows an example where an atexit function calls printf, so the standard streams are not really closed at that time. Something else is at work here, probably. > > 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. IME, being able to examine the sources was invaluable in quickly resolving some issues.