Re: MSYS2 PATH problems with native compilation

["Óscar Fuentes" <ofv@wanadoo.es>]

Eli Zaretskii <eliz@gnu.org> writes:

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

It is a package dependency, meaning that if the user installs the emacs
package, it is guaranteed that libgccjit will be installed too.

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

DLLs that Emacs load dynamically are not a problem, they all work fine
(including libgccjit dll). The problem is for executables invoked by
Emacs, because Emacs searchs for them using exec-path (which itself
depends on the initial value of PATH.) This is different to what
CreateProcess does which, as you very well know, always searches the
executable on the same directory as the calling process' executable,
first thing. This means that Emacs deviates from the stablished rule on
Windows, and that deviation causes a degraded experience.

To recap: libgccjit dll is fine, but as.exe/ld.exe/etcetera are not found
despite being installed right there along emacs.exe.

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

From your POV, of course. I'm talking about making changes to Emacs.

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

We could locally patch Emacs, of course, but "fixing" the upstream
project is preferable.

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

This is not about DLLs, as stated above.

The general problem is that Emacs is installed along all the tools it
needs, but they are invisible to Emacs unless you explicitly say "they
are right there where you are!". That's not the experience we get on
GNU/Linux and other systems, where Emacs has no problem finding any
executable as long as it is installed where the package manager puts it
by default.