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: corwin@bru.st,  bartosz.bubak@gmail.com,  58318@debbugs.gnu.org
> Date: Fri, 07 Oct 2022 13:42:15 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> It shouldn't try to compile .el(c) files, but it needs the compiler to
> >> make trampolines to redefine built-in functions.  So a nativecomp Emacs
> >> isn't fully functional if a compiler isn't present.
> >
> > No, the last conclusion incorrect.  See my other mail in this thread.
> 
> I'm sorry, I don't follow you.  If trampolines can't be installed, then
> Emacs isn't fully functional, because you can't say
> 
> (fset 'yes-or-no-p 'y-or-n-p)
> 
> and have that be respected.  I.e., the non-functional bit is about
> redefinitions of built-in functions, which is pretty basic functionality
> in Emacs.

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?

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".

Andrea, am I missing something?

The problem in this bug is that libgccjit _is_ available, but somehow
is not functional when actually used.  (The details are still sketchy
and not understood well enough.)  This situation might not be
supported yet, but when we understand it well enough, we should make
Emacs behave the same as when libgccjit is unavailable (perhaps with
some more specific message in *Messages*), because nothing else makes
sense.