Re: MSYS2 PATH problems with native compilation (was: msys2 build path problems + copy-paste english results in chinese characters)

[Eli Zaretskii <eliz@gnu.org>]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 06 Dec 2021 01:38:14 +0100
> 
> I just checked in the recipe for building Emacs 28.0.90 on MinGW-w64
> (MSYS2) with native compilation enabled and found a serious problem.
> 
> The Emacs MinGW-w64/MSYS2 package now depends on libgccjit package,
> which means that libgccjit will be present when Emacs is installed.

What do you mean by "depends on libgccjit"?  Are you linking Emacs
statically against the libgccjit DLL (via the import library)?  If
not, Emacs on Windows loads libgccjit dynamically, when it is first
requested, and it doesn't need that library to start.  So
theoretically, MinGW64 users could decide not to install libgccjit, or
have it unavailable to Emacs, and they will still be able to run
Emacs, just not to natively-compile *.el files that you didn't compile
ahead of time and provided in the binary distribution.

> But if Emacs runs without its bin/ directory in PATH, libgccjit is
> not functional (an error about missing as.exe is shown.)

Only if you try to natively-compile *.el files (or Emacs tries doing
that in the background).  And, as you point out, not only libgccjit is
needed if you do want to compile, the assembler and the linker are
also needed.  So the PATH problem is not only about libgccjit.

> Creating a desktop icon for runemacs.exe and starting Emacs from there
> is common. Also for MSYS2 users is common to work with multiple
> architectures (mingw, clang, ucrt with their 32/64 bits variants)
> simultaneously, and putting the binaries of one of those architectures
> in global PATH is problematic.
> 
> Hence it would be very convenient to use libgccjit without touching PATH.

How is libgccjit different from any other DLL that Emacs loads
dynamically, like libpng, for example?  How do your users, who work
with multiple architectures, cope with that wrt other DLLs that Emacs
uses?

> I ask again: would it be ok to add emacs.exe directory to PATH from
> runemacs.exe or emacs.exe itself?
> 
> Set PATH for the emacs instances used for generating the .eln files?

"OK" from what POV?  The MSYS2 project makes its own rules for
configuring binary distributions, and those decisions are not
necessarily aligned with the upstream project.  Why do you ask here
whether something you'd like to do in your distribution is OK or not?
If you want to know my opinions, you already heard them.  (And I still
don't think I understand the underlying problem, even after your
additional explanations, see above.)

> Other solution?

If you cannot put a DLL on PATH, the usual solution is to have it in
the same directory as the .exe which needs it.  Would that be a
satisfactory solution for your problems?