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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Andrea Corallo <akrl@sdf.org>,  corwin@bru.st,  bartosz.bubak@gmail.com,
>   58318@debbugs.gnu.org
> Date: Fri, 07 Oct 2022 14:04:57 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe there's a misunderstanding of what you meant by "if a compiler
> > isn't present".  By "the compiler" do you mean libgccjit, or is it GCC
> > and Binutils (or maybe all 3 together)?  IOW, are you talking about
> > the ability to load existing *.eln files, or are you talking about the
> > ability to both load existing *.eln files and produce new ones?
> 
> I'm talking about trampolines, nothing else.

Trampoline generation requires all the 3 components to be present,
AFAIK.  Andrea, am I right?

> > The startup code currently detects that libgccjit is unavailable or
> > cannot be loaded, and if so, disables all the aspects of
> > native-compilation: both JIT compilation of *.el and production of the
> > trampolines.  I'm not aware that when we disable those two, we get
> > Emacs that is not "fully functional".
> 
> If native compilation is disabled in a native-compiled Emacs, then 
> 
> (fset 'yes-or-no-p 'y-or-n-p)
> 
> doesn't work (for calls to `yes-or-no-p' in native-compiled code).
> That's what I meant by "not fully functional".

If it indeed doesn't work (and I wasn't aware it didn't work), we
should try fixing it, if that is feasible.