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: Sun, 25 Feb 2024 08:33:16 +0200 Message-ID: <86edd1xdcj.fsf@gnu.org> References: <864je1m0mn.fsf@gnu.org> <86cysn1tbr.fsf@gnu.org> <86bk871j90.fsf@gnu.org> <86bk86yxbs.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16246"; 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 Sun Feb 25 07:34:19 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 1re85a-0003yo-MN for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Feb 2024 07:34:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1re84h-0007ts-7F; Sun, 25 Feb 2024 01:33:23 -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 1re84e-0007tY-Mo for emacs-devel@gnu.org; Sun, 25 Feb 2024 01:33:20 -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 1re84e-0001N9-7F; Sun, 25 Feb 2024 01:33:20 -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=L/uTnmXHxmr00+yx/O8cr3blpgldfl9HkqWl/0rOqbw=; b=cAmGccL4Uem1 HzL4IDgS0A7V5K7HC99driX7IOGnn9QV9zmHiJOYMzmu+PO2zY/U3vEDrai38hY+idQJUMxOVuTtI 73Xzj7ktVSuUF+vYd61aUrCPBg9PG/WMXVFrtS796wMjbA8hILf91A8hk4BqoqWg460ria732UjaV XZ9Poj2T/bVbHCqjIhoON3v1CrnpwX0HYAYVXHEZaVG3UOEhtyo1qa7RyVC0/lpyU0FIu9pJYIcxC m8C80G+S3SFKvlve60Luw+ul8htoCVHm6zIfGbGLJ8bOEWE4tkSx8uF7Z8wcZSTPrLglXHRAVg25v VueUoFllZ9aflPKvkAZxuA==; In-Reply-To: (message from Arthur Miller on Sun, 25 Feb 2024 00:11:10 +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:316506 Archived-At: > From: Arthur Miller > Cc: emacs-devel@gnu.org > Date: Sun, 25 Feb 2024 00:11:10 +0100 > > Eli Zaretskii writes: > > > There are comments there which explain the rationale. If you are > > saying that in the UCRT build something goes wrong that violates the > > assumptions of this code, please tell the details. Specifically, > > which of these three operations indicates a failure: > > > > const bool some_pending = (__fpending (stream) != 0); > > const bool prev_fail = (ferror (stream) != 0); > > const bool fclose_fail = (fclose (stream) != 0); > > prev_fail sometimes fail with Operation not permitted. > fclose fails always with -1 What is the value of errno before and after fclose, in particular when ferror does NOT fail (i.e. prev_fail is false)? > > question is: which of the libraries linked into temacs seem to define > > _snprintf, or if none do, how does the linker resolve the calls to > > _snprintf in w32.c, w32fns.c and sound.c. If you cannot figure that > > $ nm -a nt/cmdproxy.exe | fgrep _snprintf > 0000000140004060 D __imp_snprintf > 0000000000000318 ? ucrt_snprintf. The __imp_snprintf means it expects the function to be pulled from a DLL. Which is wrong, AFAIU; see below. > $ nm -a src/sound.o | fgrep snprintf > 0000000000000000 t _snprintf.constprop.0 > U _vsnprintf > > $ nm -a src/w32.o | fgrep snprintf > 0000000000000bd0 t _snprintf > U _vsnprintf > > $ nm -a src/w32fns.o | fgrep snprintf > U __mingw_vsnprintf > 00000000000017d0 t _snprintf.constprop.0 > U _vsnprintf > 0000000000001800 t snprintf.constprop.0 OK, this means _snprintf in the UCRT case is defined by some header. And indeed I see its definition in stdio.h, for UCRT only. So I think your original change was OK after all, and I have now installed it with a comment explaining why. > How can I see which dll are they actually from? I tried with objdump but I > didn't got anything. Scanelf does not understand coff. You should be able to use "nm -g SOME.DLL" to show the symbols exported by that DLL; those marked "T" are functions. But I don't think you need that: the above clearly tells us _snprintf does NOT come from a DLL, its code is included in the executable (that's what "t" means in the nm output), which can only mean it is either defined inline in some header or in the program sources themselves. > Yes, I have seen that, and expected those to conflict; but there is much more > conflicting than just those defined in cmdproxy.c. Basically every symbol from > stdio is conflicting, not just those defined in cmdproxy itself. I think it is > fishy,but perhaps I am misunderstanding that. > > Can it be that fclose is trying to close a wrong pointer or something like that, > because pointer from one library is (wrongly) passed to a wrong library? But the fclose problem does not happen in cmdproxy.exe, it is in emacs.exe, right? So this is not relevant to the fact that cmdproxy doesn't include stdio.h. > Another question: the build process compiles one lisp file at a time It takes > quite long time to recompile. Is there some special reason a separate Emacs > process is created per each Lisp file, instead of single Emacs process compiling > all lisp files in batch? Yes: we want to compile each Lisp file in a clean environment, unchanged by loading any other Lisp files. > Just so we can call make with -jN flag? You can use -jN, and that speeds up the compilation quite a lot. On my system I use -j16, and I can bootstrap Emacs in under 4 min.