From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: MinGW build on master broken by Gnulib update Date: Thu, 5 Sep 2024 11:49:19 -0700 Organization: UCLA Computer Science Department Message-ID: <88120d34-a38a-448b-bdc3-739bcd3d1f4a@cs.ucla.edu> References: <86y1464pvo.fsf@gnu.org> <1b42ff1a-1e11-4d09-a4e2-0b51ceef5b85@cs.ucla.edu> <86jzfq2d3e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22053"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: emacs-devel@gnu.org, luangruo@yahoo.com To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 05 21:05:00 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 1smHmu-0005cc-1W for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Sep 2024 21:05:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smHXs-0000ji-9o; Thu, 05 Sep 2024 14:49:28 -0400 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 1smHXo-0000jS-2K for emacs-devel@gnu.org; Thu, 05 Sep 2024 14:49:24 -0400 Original-Received: from mail.cs.ucla.edu ([131.179.128.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1smHXm-0005AV-8J; Thu, 05 Sep 2024 14:49:23 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id D7B843C082C91; Thu, 5 Sep 2024 11:49:19 -0700 (PDT) Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id CSheroMqXJWT; Thu, 5 Sep 2024 11:49:19 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 820CD3C082CB6; Thu, 5 Sep 2024 11:49:19 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 820CD3C082CB6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1725562159; bh=tZ5QwKWwjSJKdz71Xh0VTVdXQXtQzLVLLhKXpxOupbM=; h=Message-ID:Date:MIME-Version:To:From; b=lHXJY7CeaDK9dZKMlvq+RzVOqf0pi5kP6KCZ+0jXadqh0o5UeJJgL5xjPzeP5H5XA L5uxkAR/cxyimwsqx1a9q0Zzujt2BirCyBvHabsnCyYLTIqCIm5RgiPKWJ7s/ZAkJ3 MTtsadyCWM+4rIEuNnaai5uO3tzwUjvDyfDPqq8YWIC82/3Gx/qYAsrKepEpiolrRM bUTLhSno9W6syw17y+3A7W2scg8xqbhHWulQ70FG+MGRxNtOHJycsDtQT9seWxcNnm EIkqNcZMMeXfJ69C1V05cX73+rM8v33JjYk/z3MxzL4zyVY4DZrtHTRe+8sUKKbuWF E245VG2Rs5iRg== X-Virus-Scanned: amavis at mail.cs.ucla.edu Original-Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 7Wj5swOK3876; Thu, 5 Sep 2024 11:49:19 -0700 (PDT) Original-Received: from [192.168.254.12] (unknown [47.150.137.250]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 5EC3A3C082C91; Thu, 5 Sep 2024 11:49:19 -0700 (PDT) Content-Language: en-US In-Reply-To: <86jzfq2d3e.fsf@gnu.org> Received-SPF: pass client-ip=131.179.128.66; envelope-from=eggert@cs.ucla.edu; helo=mail.cs.ucla.edu X-Spam_score_int: -19 X-Spam_score: -2.0 X-Spam_bar: -- X-Spam_report: (-2.0 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham 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:323427 Archived-At: On 2024-09-05 11:02, Eli Zaretskii wrote: > I'm talking about what's in the sig2str.h header. The above URL says > nothing about it. Why cannot Gnulib arrange for that header to > declare these functions and that macro, if signal.h didn't? Because then callers might easily make the mistake of thinking that they should include to declare sig2str. Callers shouldn't do that. They are supposed to include to declare sig2str. sig2str.h is for something else: it's for defining SIGNUM_BOUND, and it includes signal.h only to be backwards-compatible with older Gnulib versions. In hindsight I should have given sig2str.h a different name. I wrote sig2str.h decades before POSIX standardized sig2str, so I have some excuse for this infelicity. We can change sig2str.h's name now, if the name is so confusing that it's worth the hassle of changing. >> Instead, how about adjusting Emacs's MinGW shims to supply the missing >> declarations? Something like the attached patch, say. (I don't use MinGW >> so can't easily test this.) > > This might solve the Emacs problem (and is not very clean even in that > case), but will not help other projects that use Gnulib. That's not something we need to worry about. Gnulib's sig2str module depends on its signal-h module, so other projects that use sig2str get the POSIX-compatible API with no fuss. The MSVC port of Emacs is a special case, because it deliberately suppresses the Gnulib replacement for signal.h and supplies its own declarations for signal-related functions like sigaddset, sigprocmask and sigaction. sig2str is simply another function to add to that longstanding list. I doubt whether any other project does anything similar. If there is one, it will have its own special reasons and will need to accommodate them. If that ever happens, we can then worry about whether its accommodations can be shared via Gnulib with Emacs's; this will surely affect many functions other than sig2str. In the meantime, as you mentioned the Emacs patch I proposed is good enough to solve this particular problem. > Once again, assuming every program that needs sig2str should also use > the Gnulib signal.h header is IMO wrong. The issue is not just sig2str; it's also sigaction and many other functions. And the issue is not limited to signal.h; it's also present in stdio.h and many other standard headers. Gnulib's design principle is to make the API resemble the GNU API as best it can. Of course that principle could be changed if needed, but any such change should be discussed on bug-gnulib@gnu.org, as it's a much bigger issue than just sig2str and Emacs.