From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Compiling in mingw-ucrt runtime Date: Sun, 25 Feb 2024 00:11:10 +0100 Message-ID: References: <864je1m0mn.fsf@gnu.org> <86cysn1tbr.fsf@gnu.org> <86bk871j90.fsf@gnu.org> <86bk86yxbs.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="12016"; 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 Sun Feb 25 06:45:39 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 1re7KU-0002ss-H1 for ged-emacs-devel@m.gmane-mx.org; Sun, 25 Feb 2024 06:45:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1re7JR-0004Oi-ER; Sun, 25 Feb 2024 00:44:33 -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 1re1Aq-0002QH-0X for emacs-devel@gnu.org; Sat, 24 Feb 2024 18:11:16 -0500 Original-Received: from mail-ve1eur01olkn2086.outbound.protection.outlook.com ([40.92.66.86] helo=EUR01-VE1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1re1Am-0006Co-BP; Sat, 24 Feb 2024 18:11:15 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dWkV2C9OF/GNfal+j31M2CRxHvcphmd6IgqTgk24nVZjQ+GcA8FeKN+Tt8az51v6u4G22Zm0a71rw3DS1I/GW1JOusZi9icjcPtnd7oFjiXgAO+IWSjA87hMoAiJdryvMUw1hLHB+DB6GbvhMoTBib7Vk+HNPyf9tjDgpDdr+R24oaJ7ab2daBWx+RkfqAb2jHKD4Spk1Bzt6qW6/7xCraaD0uFglDD8Xnk+tx/1keBCqnP9COsmb5c3tSAwUL5puitXP4kpuhGWWlZih0U84dMtI3CJnk7KzHFvH/T/t0gTsgJfCE2dwsZrbZSUBvtrofT6sNR+7ssVDx/pW0qfAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=U6XAw+wouV9yTD5Gu3/7K1T9ewA+FnED1zEyOtcG9oU=; b=UcX+45V+XHQ4M/Q5HtEZOxxNldlTmwYqpVJxAdiM9GTEVYs2bs/YuRX+B3DHbrxTaI884I/xlyBR8AL8pUokvxBpxzgibbkEE9Q/W8/6pcxRbDTjbDkjoBEETCRfg8MJSvHj4VW3/61bNLohg3mqDK3f7YkScgrY3EXY589i6oM+qu2vfcvZ3HXBdHBswMS5sE+xPf0PZacfiK/pEG92V3uczuFad2ClaGju8H9YRN6J1Aw+jXLGq/lwj2g4ykNiJasa97tvn9dDRgrt5qQB++kCv2Fjq/Ycg+LgoSWoA+RBOYIyyG0ITnxENtjA+qe1c3XWgCTkrZdruV8sgco7jA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U6XAw+wouV9yTD5Gu3/7K1T9ewA+FnED1zEyOtcG9oU=; b=SV6IXnmeeEE29g7JOSMqtbaUthPrfrjuWr3nd/xyzagYRnfBGT9K+j/X2TZntwfWbIgfBO3Ri3bhi/BfHMvSZfDo5nDkPPBEfaDVKHMrSLDSYQnhhu2GMvfCbuhrbek+qxYsbStTkEV2VY3TykHlj69M1m0T30uTv2ncs7F9KHZ0QW9klU9f3SLM+izlc+wptck/MJ9iEvWcg/F1CFEhZWI0RNqGkMV+M/IrvPfFuJ7ZSSM9ETpvVo7hH61jnjWGlZ6u+LZC4/2ZdoiObM6TgFILvMRK4dhimnP6XUkL+r/n9d/vWfhUGwMvZOwwvSMICOBr7FbiN8m1ZYgRWpl1RA== Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) by DB8PR02MB5899.eurprd02.prod.outlook.com (2603:10a6:10:118::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7316.31; Sat, 24 Feb 2024 23:11:07 +0000 Original-Received: from DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::b4ad:e01a:924c:52e]) by DU2PR02MB10109.eurprd02.prod.outlook.com ([fe80::b4ad:e01a:924c:52e%7]) with mapi id 15.20.7316.023; Sat, 24 Feb 2024 23:11:07 +0000 In-Reply-To: <86bk86yxbs.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 24 Feb 2024 05:24:13 -0500") X-TMN: [uUpINqyGzZv7EVMdFgHgrg9iYflZ/TO7] X-ClientProxiedBy: OL1P279CA0013.NORP279.PROD.OUTLOOK.COM (2603:10a6:e10:12::18) To DU2PR02MB10109.eurprd02.prod.outlook.com (2603:10a6:10:497::14) X-Microsoft-Original-Message-ID: <86v86dsbjl.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DU2PR02MB10109:EE_|DB8PR02MB5899:EE_ X-MS-Office365-Filtering-Correlation-Id: 14ef7abe-a237-49b2-7899-08dc358de1c6 X-MS-Exchange-SLBlob-MailProps: quCBMN2EvO/aDi/tpXFpa1daPycnmzAcE9mUA2YzLIbOfsjs8fKl3Yy7Ox3260QY4UoCsMhyUNiftI+IVlj45yysPkBBa0J7plZ/meu+ncUZdI1oGPTtHMFcJQjGmjcOkMupzHBJ7CfrTdJ4wzgdi8d1jZPuJEfUiuF3hvKDA/Kz1k2xt1l5qAbRVXAxHQ+q+QW4JjtsnVWDFCCMQ2ihNP1amiNzuUOj+9pJtpkCLrW1P915x+Jd9IpDRFjkWY8PSxYdAY8TZANED0f4I+YH0sgI+5yryfQ5y/TQkMHaMtqFIPJLiv6LxeT7BXKR3KwgbEX+UNQBsYhPi+vYExlWKKgqWr8J0K0cQ4n3WamnHlW7SMf00CR22Sqi+pTXbvvyII3xGlhH/jsFsZLinU0Rl+7msb6nzQERiC5BBla6iA56CiEUSqolm9Qm1QDEU2hA1zQLgPs+98nkzilfI29rH1YdjUzU5IjXrvmPXIs48YwrdwUYa70gED5X57HaJoBIGeBi4vzeZ+rVSyotNDmEuAdPjNOCkt91zlPMBkxDlRJmcQ5iHfvkUQ3dNV646uDkLheDVNebHSNeKki5ZvwPfAUxV7YfPl1yZw/XxFaE54C6A+y65DM06UZQPMfpOrQSvedi1sq0veg8XjnqRUdaZ5I+zvHefjL5pcV3o8bFvqdOkK6DzCp5HoiN0xR9atpLztIH9MdpqUfJdDea5ZFBbw== X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: mVL/J0F7vDcIcV1P3DfsPAnBVwgRSpvlo/K0aIkUznrdbkQ4YnWSgHlwlTpAsswO4hn4YRLSJvgXqvUKTZgOQdUXb9+YUZRJfs9QDDUni0TnMC9yAWISBIk/3ysF+lo5yRQjL3dWpqacJGZFBRUz0s+9jvLACzEWTYcTcuKe2gf6szVdY9R8uiioP5fQXAzfN6No2ozlGPmqSUhPERC44xsqd2Ic6s1TkDsPRj07EuXVcAWqT8sgOrWJBuy+UcEshn3jMhzGZJGSXZ3RFIk1FzKZ4vVmwNmcHc8ksBhjPDLDdUVIX1qCt+s1zPjM0OKMLfugS+iEVOtyZ+JmZlGz/JSkt/AOWjQ3CKEzhoy2TbT5RTK8tDzcypouHlH9IxxOwLkX/jM7zHMRWYXSqFIqbnpz61p6desDBN37MeYzdL8PEG7GRVQyyS3Xcj4X7r+1pPQedPHh/uEVaz5K8WIaZkk2h6ZjnBcMIaDlhkOIUqNA472yBrn/KySbjwoDCPB4z3w8QEvoFaVnw0sHfRqc2uFKPDRjzIqIfluu9Xs5HtGBpmQQWg6Y+As3cSVGjQTB X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?o2YwxvgQL4w7BvKn+/F/xuTaOPllRBvFdnbCgCREdr+xIo+9v9O9YODh2CYu?= =?us-ascii?Q?XJ56UIihNZinkfaxxO3dH5FnKd+5isT+Pff1igN9pb/z1t5ihGqzrPi2KlVl?= =?us-ascii?Q?i+Ib5ZkkbV0xvsmaV80mpa2RlBPioNUdtpIzZ6NISk+v0InpRB1imGReIujN?= =?us-ascii?Q?fUTLDBhZ0o/nMnfNqCRAy7h2U+v4g2GmEmP9Tgz3yN46341fA1TtI1GmBUGB?= =?us-ascii?Q?B9ByBecQHNOc5zprikqompr937xvNFi1768B3nkbywHLtr5tupW3hnuLv/P9?= =?us-ascii?Q?kvMe4S3OfsvnrhEG2oabHvPeL4I+zbEIWi2z5+NLXyldGv16XsEaB8BUCIOX?= =?us-ascii?Q?ktRV928UR77u/MhF78HxY7jPCRECRKrwpKVGjjN+jHMZel2SA5PDVz9qtyGk?= =?us-ascii?Q?xrpbALSQC1WcWE5u6SqRiCDEt9+eBf8v1iw4FtvOjcl7actSgcg5qkC9BJbB?= =?us-ascii?Q?H03cADf0bGv10kpnVbX5OjjUCHs+ThProqZpOFOrSRvvzgr+aQlRJHVRb6dg?= =?us-ascii?Q?zxM14NJeBlKExOAv01b01KFIb4eY6A2HTuXKLh1piBLSeBxl+RhBmpgp+Q+R?= =?us-ascii?Q?rRyynXrQA/RE3pwYzQK715gxDum8NrZYAqXZsfVo09DG20Qu5cnZ7iX+xxAA?= =?us-ascii?Q?RX X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-ab7de.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 14ef7abe-a237-49b2-7899-08dc358de1c6 X-MS-Exchange-CrossTenant-AuthSource: DU2PR02MB10109.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2024 23:11:07.7741 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR02MB5899 Received-SPF: pass client-ip=40.92.66.86; envelope-from=arthur.miller@live.com; helo=EUR01-VE1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Sun, 25 Feb 2024 00:44:31 -0500 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:316503 Archived-At: Eli Zaretskii writes: >> From: Arthur Miller >> Cc: emacs-devel@gnu.org >> Date: Sat, 24 Feb 2024 10:13:45 +0100 >> >> Ok; I have looked at close_stream :). Why is it clearing errno on prev_fail? >> >> if (! fclose_fail) >> errno = 0; >> >> I don't think it is meaningful to signal to client code that operation failed, >> but clear the errno so the application can't figure out why and recover. > > 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 > You can answer that question by printing the 3 values, or by stepping > through the code with GDB. Yeah, I know Eli; thanks. :) >> But perhaps I just don't understand the details. Anyway, I don't >> think that is the problem here. >> >> I think the problem is that different libraries are mixed. I am not 100%, >> because I am not familiar with the build process, but what I see is that ldflags and >> cflags seems quite different for temacs vs cmdproxy: > > Of course, they are! temacs is a large application with GUI > capabilities, and calls a lot of Windows APIs, whereas cmdproxy is a > relatively simple console application that just calls the shell. The I didn't expect them to be identical in the sense they will link against all the same libraries and have all the same command line switches. I don't see -DUSE_CRT_DLL=1 in temacs object; so I am just suspecting there are some different dlls from different places with same symbols in game, but I don't know how the build works. Perhaps they are both linked to the same ucrt runtime anyway. > 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. $ 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 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. >> I have also tested to include in cmdproxy.c; then I get conflicting >> redefinition and conflicting declaration for printf and basically everything in >> stdio: > > That's not surprising, since the comments in cmdproxy.c say: > > /* We don't want to include stdio.h because we are already duplicating > lots of it here */ > extern int _snprintf (char *buffer, size_t count, const char *format, ...); > > So don't do that. 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? >> I have also a qeustion; I would like to understand better how Emacs get built, >> so I wonder why does it include half of the gnulibc and core-utils in lib >> directory? > > It isn't gnulibc or core-utils, it's Gnulib, the library that provides > implementations of functions missing from C libraries that are not > glibc. Emacs uses Gnulib to avoid too many #ifdef's in its sources, > where some function needs to be used that is not guaranteed to exist > on all platforms -- in such cases we use the Gnulib replacement. Ok. Thanks. 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? Just so we can call make with -jN flag?