bug#58318: 28.2; Emacs installed from package won't work with MinGW

[Andrea Corallo <akrl@sdf.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: larsi@gnus.org, corwin@bru.st, bartosz.bubak@gmail.com,
>>         58318@debbugs.gnu.org
>> Date: Fri, 07 Oct 2022 13:04:55 +0000
>> 
>> > How is this relevant only to Windows?
>> 
>> Windows is the only system where a native compiled Emacs can start even
>> if libgccjit is not present.  On GNU/Linux we get and error at load time
>> from the dynamic linker in case.  As a consequence on GNU/Linux Emacs is
>> always capable of producing trampolines when needed.
>
> It could be that libgccjit is loaded but is incompatible or
> something.  So I'd prefer a general solution.
>
>> > And what do you mean by "disable direct calls from Lisp native code
>> > into primitives"?  I don't think I understand what this would do in
>> > practice.
>> 
>> Native compiled elisp calls directly into primitive functions not to go
>> through funcall.  For this reason when a primitive is redefined we need
>> to produce a trampoline in order to forward these calls to the funcall
>> machinery.  If we disable all of this optimization the issue disappears
>> but indeed that's not good from a performance point of view.
>
> How much will performance suffer if we use funcall?

This is the usual 1 milion dollar question, we can run benchmarks but we
are never sure of how much realistic they are.  That said IME this is
one of the most effective optimizations we have, funcall is a non
trivial and relatively slow machine when executed at each function
activation.

  Andrea