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: MinGW build on master broken by Gnulib update Date: Thu, 05 Sep 2024 21:02:29 +0300 Message-ID: <86jzfq2d3e.fsf@gnu.org> References: <86y1464pvo.fsf@gnu.org> <1b42ff1a-1e11-4d09-a4e2-0b51ceef5b85@cs.ucla.edu> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15184"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org, luangruo@yahoo.com To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Sep 05 20:03:26 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 1smGpK-0003gT-9p for ged-emacs-devel@m.gmane-mx.org; Thu, 05 Sep 2024 20:03:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smGoV-0008UT-EK; Thu, 05 Sep 2024 14:02:35 -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 1smGoT-0008TE-SZ for emacs-devel@gnu.org; Thu, 05 Sep 2024 14:02:34 -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 1smGoS-0008AF-3g; Thu, 05 Sep 2024 14:02:32 -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=inClxyLHz9hhqh3C/3vVNtncGvhaUk+YPU9iUtlEkaY=; b=dbgVzzJwJBMW gzzg+ab2PWSVArJaDXdDnUXtUucQvypiOqpTZamumoV2aq/WKG3dXNSd2v/SRJ+vzWnRuxGKAj+LV iznbrNDJGhpFl3QaT3Dw6t2EtXb2QeteE7k+LtYvvJ5vsX8XUISdNj4tP64GFJmB9QNt0dDMwaLaZ K7V2oavBjeHVqTapU9KUFR2DP+w74QO8l+fo70sLmmbHzBLu2rDZ4uiqZn8vAU9VOckRFVN86WZis adum6JD8tIO5oo36NzN/hVe1+QBisQfQ/Sanboy6XT4jIKLhUOK2QskqmK2l11Vf6iZMpqazCMhoR 38esRc1Bji4OtbAUdcTC4A==; In-Reply-To: <1b42ff1a-1e11-4d09-a4e2-0b51ceef5b85@cs.ucla.edu> (message from Paul Eggert on Thu, 5 Sep 2024 09:28:15 -0700) 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:323425 Archived-At: > Date: Thu, 5 Sep 2024 09:28:15 -0700 > Cc: emacs-devel@gnu.org, Po Lu > From: Paul Eggert > > On 2024-09-04 22:43, Eli Zaretskii wrote: > > > Gnulib moved the prototypes of sig2str and str2sig from sig2str.h to > > Gnulib's signal.h, evidently assuming that a build which uses the > > Gnulib sig2str will also use the Gnulib signal.h header, but that > > assumption is false for the MinGW build of Emacs, which omits > > lib/signal.h (because it clashes with some w32 code in Emacs). > > > > I fixed that temporarily by modifying lib/sig2str.h to include the > > missing stuff for MinGW, but this is really a Gnulib issue, and should > > be fixed in Gnulib, IMO. > > The change to Gnulib was to align with POSIX.1-2024, which declares > sig2str and str2sig in ; see: > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/sig2str.html > > We don't want sig2str callers to depart from the POSIX API, any more > than we'd want to require (say) fdopen callers to include a > Gnulib-specific fdopen.h rather than including . 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? > 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. Once again, assuming every program that needs sig2str should also use the Gnulib signal.h header is IMO wrong. The Gnulib signal.h pulls in too much stuff, including pthreads (which are a major source of trouble on MS-Windows), and a lot of other signal-related stuff which will get in the way of any project that wants decent emulation of Posix signals that are not available on Windows (and thus require custom code to emulate, similar to what Emacs does with SIGKILL and SIGPROF). By forcing projects to use the Gnulib signal.h header when all they need is sig2str, you are making porting of GNU software to Windows much harder, in an area where it is hard enough already. I urge you to reconsider and find a way of allowing projects to have sig2str without also using the Gnulib signal.h. I don't think the changes in Gnulib should be too complicated (there are already ways of testing in Gnulib headers whether a given function is replaced by Gnulib, and the declarations are needed only in that case), so I hope the Gnulib will agree to such changes and not make porting programs to Windows any harder in this area. TIA