bug#45303: #45303 [feature/native-comp] building error on Windows

[Andy Moreton <andrewjmoreton@gmail.com>]

On Sat 19 Dec 2020, Eli Zaretskii wrote:

>> From: Andy Moreton <andrewjmoreton@gmail.com>
>> Date: Sat, 19 Dec 2020 14:35:45 +0000
>> 
>> b) Linker error for "strsignal"
>>    This seems to be a configure problem. On master the configure test
>>    for strsignal fails to link, and the gnulib replacement get used.
>>    On the native branch the configure test links successfully, so the
>>    gnulib replacement does not happen. The only difference in the
>>    conftest command line appears to be adding libgccjit, so somehow
>>    that library is providing a strsignal symbol.
>>    Adding "ac_cv_func_strsignal=no" in nt/mingw-cfg.site appears to
>>    suppress this problem, but I don't know if that is the right fix.
>
> I must be missing something, because I don't see strsignal used on
> master in the MinGW build at all.  Moreover, Gnulib's strsignal.c is
> not even in lib/.  We call sigdescr_np instead.  So I wonder how did
> you see that the Gnulib replacement for strsignal is used on master in
> the Windows build.

Entirely possible that I have misunderstood something from reading
sources and grepping (the gnulib gyrations are hard to follow).

The emacs source calls strsignal, and something provides it (whether via
a macro replacement or a linkable symbol). The only difference I could
see was the configure test, as noted above.

I see that src/syssignal.h has a replacement macro:

    #ifndef HAVE_STRSIGNAL
    # define strsignal(sig) safe_strsignal (sig)
    #endif

So is the problem that on the native branch the configure test succeeds
and sets HAVE_STRSIGNAL, resulting in trying to link the wrong symbol ?

    AndyM