Re: MSYS2 PATH problems with native compilation

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 06 Dec 2021 23:48:28 +0100
> 
> 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.

So you were talking about libgccjit, but actually meant the assembler
and the linker programs, not the libgccjit DLL?  That was hard to
guess.

If the problem is with the Binutils that are invoked as part of the
compilation, then I think I understand the problem even less.  For
starters, AFAIK we don't search for those in the Emacs code, it's
libgccjit that invokes them in its own code, according to the rules of
a "usual" GCC installation.  Andrea, am I mistaken?  I don't see any
use of exec-path in the nativecomp code that would look for the
assembler and the linker, am I missing something?

If I'm right, then nothing you do with PATH in Emacs can guarantee
that native-compilation will find Binutils, because that depends on
how GCC and Binutils were installed and how they search for the
programs they need.  IOW, I believe that libgccjit relies on a
functional GCC installation, including the subprograms under libexec
and (perhaps) some system header files?  I don't even know what it
expects, because AFAIU its prerequisite is a working GCC and Binutils
installation.

But if PATH does make a differenceand can solve your problem, by some
indirect way, then did you try to put the assembler and the linker in
the libexec/emacs/ tree, where we keep auxiliary programs Emacs
invokes?  Emacs searches there by default.

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

You want Emacs to change the user's PATH by default?  That'd be
unthinkable, IMO.  Programs have no business messing with user's PATH,
since that could easily mess up user's system.  E.g., suppose the user
already has a development environment installed and on PATH: then you
are silently causing "M-x compile" to use different Binutils programs
than what the user intended.

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

I don't know what kind of GNU/Linux installations you have in mind,
but I don't know about any reliable installation technique that causes
all the installed tools to seamlessly work together, except by either
modifying PATH or installing all the tools in the same common tree.
Anything else is much more complex and fragile.  Having several
incompatible development environments on the same machine active
simultaneously is IME a very rare use case, but if your users do that
frequently, and you don't have some system of batch files/scripts to
easily and reliably switch between the environments, then your users
are in for a lot of trouble.