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: Compiling in mingw-ucrt runtime Date: Fri, 23 Feb 2024 14:02:19 +0200 Message-ID: <86bk871j90.fsf@gnu.org> References: <864je1m0mn.fsf@gnu.org> <86cysn1tbr.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14414"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Arthur Miller Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 23 13:03:41 2024 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 1rdUHE-0003Yx-2G for ged-emacs-devel@m.gmane-mx.org; Fri, 23 Feb 2024 13:03:40 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rdUGY-0003y4-2S; Fri, 23 Feb 2024 07:02:58 -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 1rdUGK-0003dW-DT for emacs-devel@gnu.org; Fri, 23 Feb 2024 07:02:44 -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 1rdUG3-0002u4-FO; Fri, 23 Feb 2024 07:02:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=uzy4mDckZx6bz/LPzfv/MOHq3LZSoEt83jZA3Rwl/Cs=; b=j2OslsMbBta7 yVRFtlK6sPUEfOVPxnPRiDNjj3FbPAMDsFwSFJfsFrreeL1bmWEz5DTebifoc3O2J49ejnJHGt0QZ Qg8oNHBUvBNr0HJ9AgY3HUBQldIL6HOEvDINt46e1Xe6tJnhX4rwQpWLTrsNGL/O9J2XoFdOv0h1G 6veooFKYGHccPES6j9/kORNZZ9oVh7xVPeA3N+iyc4e530gPs7KDKkpAbkvCHC0kRMivWB2Q2F+xO lMroprbQGkaDZLAn4ZQlGbH0rfwP2O+MeTATCr/YHN/u+3r6t5r/86HNTIsw2jfKrSSAwo/qxT3TK GPU03g4/EnK4EKP8URN92w==; In-Reply-To: (message from Arthur Miller on Fri, 23 Feb 2024 12:32:27 +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:316465 Archived-At: > From: Arthur Miller > Cc: emacs-devel@gnu.org > Date: Fri, 23 Feb 2024 12:32:27 +0100 > > Eli Zaretskii writes: > > >> As mingw ucrt patch mentions; MS ucrt provides snprintf so mingw does not > >> provide one in ucrt. > > > > Sorry, I don't understand what you mean by that. MinGW only provides > > some stuff that the MS libraries lack, so by "UCRT doesn't provide > > _snprintf" I meant that the combination of MS ucrt and the MinGW > > additions in UCRT mode doesn't provide _snprintf. > > I meant they explained that in mingw runtime, msys/mingw provides their own > implementation of snprintf, while in ucrt runtime it comes from Microsoft. If I > remember well from the time I uset to write some win32 code, Microsoft used to prefix > all posix functions with and underscore, so snprintf turned into > _snprintf. Perhaps mingw just followed that convention by Microsoft. And now in > ucrt Microsoft don't underscore posix names? No idea really; just guessing. I am > not familiar with how msys/mingw folks do their patches and what is included and > what not. I can understand that UCRT doesn't provide _snprintf, but then I don't see why all the calls of _snprintf in w32.c and w32fns.c don't cause the same problems in the UCRT build. Perhaps indeed some library is linked into temacs.exe but not into cmdproxy.exe. > >> Yes, I agree, it is all about close_stream. Seems like it is all the same error: > >> -1 (unspecified error). You can see the test from the patch. > >> > >> I haven't seen the code for close_stream or msys patches; I will have to > >> download and look at it; but it sounds plausible as you said that they probably > >> don't clean up errno. > > > > The source fore close_stream is in the lib/ subdirectory of the Emacs > > source tree, so you should already have it. > > Ah, I see. Thanks I'll look there. Thanks.