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

[Eli Zaretskii <eliz@gnu.org>]

> 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?

> Indeed the other option is to precompile all trampoline AOT when we know
> libgccjit is available.  It is actually very simple with something like:
> 
> (mapatoms (λ (f)
>             (when (subr-primitive-p (symbol-function f))
>               (or (comp-trampoline-search f)
>                   (comp-trampoline-compile f)))))
> 
> It was not consired worth as trampoline production is very quick, but
> might be worth at least for Windows platforms for the discussed reason.

If calling through funcall is too expensive, I think pre-compiling all
the trampolines would indeed be the best solution, thanks.