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 Brust <corwin@bru.st>,  akrl@sdf.org,  bartosz.bubak@gmail.com,
>   58318@debbugs.gnu.org
> Date: Sat, 08 Oct 2022 14:56:46 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Right, so I think we need a special Makefile target to produce those
> > compiled trampolines (something like "make trampolines"), and that
> > target should be only used manually when building a binary
> > distribution, not when building the release tarball for use on the
> > same machine where it is built.
> 
> Yup.
> 
> But I'm not sure this is something we should do, really -- it's extra
> work for something that is only important on non-free systems, and it
> will complicate the logic in general (since we'd probably need to add
> another directory for pre-built trampolines and manage those, etc).
> 
> I think we should leave this up to people who do packaging.  That is, if
> Cygwin (etc) distributes an Emacs with nativecomp, they will also
> distribute libgccjit etc (i.e., all the prerequisites).

It could be part of the scripts in admin/nt/dist-build instead, yes.

> That leaves the question of what we should do with the Windows zip file
> we (that is, Corwin) distributes, and I think we should avoid enabling
> nativecomp in that build, so that it works on the widest range of
> Windows machines.

The Windows build with nativecomp is supposed to be fully workable on
systems that don't have libgccjit, even if the libgccjit bundled with
the zip file is not installed or deleted.  If there are issues with
that, they should be fixed, because we want to allow users to move
Emacs from system top system without the optional libraries, and have
a functional Emacs, like is already the case with image libraries.