Re: MinGW build on master broken by Gnulib update

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 5 Sep 2024 09:28:15 -0700
> Cc: emacs-devel@gnu.org, Po Lu <luangruo@yahoo.com>
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> 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 <signal.h>; 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 <stdio.h>.

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