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

[Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Pal Gloss <pcfeb0009@gmx.com> writes:

>> There are still problems related to the usage of Fdirectory_files and
>> internal_condition_case_5 I think. At least, I get a crash after the
>> bootstrap is dumped (? see attached build log)
>>
>> Debugger entered--Lisp error: (wrong-type-argument wholenump t)
>
> Despite 2526032ea954671aa48a6ad6d924df2941a8364a, this error still happens:
> Qt and Qnil should be swapped (see sed script at the bottom of the mail
> inside my build commands or the git diff in the build log).

Hi Pal thanks for trying.

I don't like to run or decript scripts, I like to review and apply
patches from contributors, why don't you submit one for this? :)

>> >> With 407fb16583 I think '-lgccjit' should be unnecessary on Windows now, is it?
>> >
>> > It is still needed, see my previous mail. But adding -lgccjit allows the build
>> > to proceed but crashes later on.
>>
>> Hopefully this is fixed now by 3bb2fd0c58?
>
> Not quite: -lgccjit was still needed for strsignal.  Note that the strsignal is a
> double problem:
> 1. Because configure can link the test program with the call to strsignal because
>    libgccjit exports it (though Eli argues it shouldn't and I've reported an issue
>    to the mingw64-packages repository), no special provision is made to include a
>    header defining the function.  Hence, during compilation, there are several
>    warnings that gcc assumes that strsignal returns an int and has to cast it to
>    const char*.

Eli is right, mingw64 should fix this.

We might provide the prototype ourselfs but I don't think is a good
idea.  I think is probably better not to define HAVE_STRSIGNAL depending
on libgccjit.

  Andrea