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.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: MinGW build on master broken by Gnulib update Date: Fri, 06 Sep 2024 09:48:40 +0300 Message-ID: <86r09x1dmf.fsf@gnu.org> References: <86y1464pvo.fsf@gnu.org> <1b42ff1a-1e11-4d09-a4e2-0b51ceef5b85@cs.ucla.edu> <86jzfq2d3e.fsf@gnu.org> <88120d34-a38a-448b-bdc3-739bcd3d1f4a@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16672"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, bug-gnulib@gnu.org To: Paul Eggert Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane-mx.org@gnu.org Fri Sep 06 08:49:16 2024 Return-path: Envelope-to: gnu-bug-gnulib@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 1smSmR-00049e-MF for gnu-bug-gnulib@m.gmane-mx.org; Fri, 06 Sep 2024 08:49:15 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smSm3-0001nL-8V; Fri, 06 Sep 2024 02:48:51 -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 1smSm0-0001n0-9o; Fri, 06 Sep 2024 02:48:48 -0400 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 1smSlz-0002G0-5m; Fri, 06 Sep 2024 02:48:47 -0400 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=1Zi6FBh4azFYY2p6y5VvaW+/NhXOykJWD4xcY4JRIac=; b=cTulyzqb9bbq 0+y2CH2DpAElfKEV20/aYZiEthNrz6VbMnZRpgvu/YIyXD3+8wEI3qEmojx8za8sUOSCxGOys+hte BC1uDlYGBPeiFc314SeN1OpMbghi6HAmHVKgmqT3VI0ZdS/fKUdna2/WPMd5uVDirCeK+1vN8ilXS fNtxSrU+w3EVfiTszULqU4TN00eMkA/7m7Afo5KBvltc4S8qJCfih8zF1rjRbsP3QLWxlTynOqBms As5YDj80+qPAQ9hxv03AwZJNbzyWvVRLnulvSDU7fxdmJs0pnQJoVXbg8rBjuFurs/11X2oP3hEop 1XJL/1hLrDvowM5r5TMEag==; In-Reply-To: <88120d34-a38a-448b-bdc3-739bcd3d1f4a@cs.ucla.edu> (message from Paul Eggert on Thu, 5 Sep 2024 11:49:19 -0700) X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane-mx.org@gnu.org Original-Sender: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.comp.lib.gnulib.bugs:51613 gmane.emacs.devel:323450 Archived-At: > Date: Thu, 5 Sep 2024 11:49:19 -0700 > Cc: emacs-devel@gnu.org, luangruo@yahoo.com > From: Paul Eggert > > 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. Then document this and be done. I don't see how is this a big problem. > >> 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. That is strange to hear, since Gnulib is supposed to care about all GNU projects, not just about Emacs. > 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 There's no MSVC port of Emacs, not for many years. > 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. I have neither time nor energy for this Gnulib politics, so I went ahead and installed a workaround for this. (If I had more free time, which I don't, I'd stopped using the Gnulib sig2str.c altogether to avoid the issue in the first place, but things being as they are, I installed an easier cop-out.) If the Gnulib folks (CC'ed) are ready to reconsider, I will be happy to remove the workaround.