Re: MSYS2 PATH problems with native compilation

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 07 Dec 2021 17:09:45 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> As far as native-comp is concerned, the required feature is the presence
> of a functional libgccjit install. In my original message I never
> mentioned a dll.

libgccjit _is_ a DLL.  I understand now that you meant to name a
package instead, but expecting me to realize that, let alone know what
is the contents of that package, is a lot of expectations.  Please try
to be more explicit in the future, to make the discussion more
efficient.

> > 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?
> 
> libgccjit probably uses `system` or some other shell-related mechanism
> for invoking the assembler and linker.

Maybe so, but even if it does, it doesn't necessarily rely on PATH to
find the executables.  For example (and I don't know if this is
pertinent), if it needs to invoke the cc1.exe C compiler, it will not
generally find it on PATH.

> Having in PATH the /bin directory where Emacs and gcc are installed
> solves the problem.
> 
> > 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.
> 
> Duplicating executables here and there just to appease Emacs is a not
> very appealing, to say the least.

But above you say that placing these executables in the same directory
as Emacs solves the problem, so you are going to duplicate them
anyway, right?  Because the "normal" GCC installation doesn't
necessarily put them in the same directory, right?  And if they _are_
installed in the same directory, then what is again the problem of
adding that single directory to the system-wide PATH?

> > You want Emacs to change the user's PATH by default?
> 
> No, not necessarily. For solving the problem with libgccjit not finding
> as/ld, what I want is to set PATH for the emacs.exe instance spawned
> for compiling the .eln.

But that solves only part of the problem, because the compilation is
not necessarily in a subprocess.  Some of the comp.el commands use the
same process to compile the files.  So with your proposal, some
commands will maybe work, but others won't.

> > That'd be unthinkable, IMO.
> 
> Currently the user is forced to add emacs.exe to PATH if he wants a
> functional native-comp. Not to mention executing tools that are
> installed on the same tree as Emacs in general.

That's the user's responsibility and his/her action.  Only the user
knows (or can know) how to add a directory correctly to PATH without
messing up his/her system configuration.

> > 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.
> 
> Not if emacs.exe directory is appended.

If you append it, then there could be a different as.exe/ld.exe
earlier on PATH, and you have the same problem.

> > 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.
> 
> Precisely, MSYS2/Mingw-w64 installs everything in the same tree.

So why on Earth not tell your users to add that single bin/ directory
to system-wide PATH, and be done with that?

> Well, that's something for the user to care about. Our job is to provide
> an Emacs that works as installed, and right now native-comp is broken
> unless the user sets PATH globally.

Then I suggest to tell the users to set PATH globally.  That's the
correct solution, on any system, because it makes the MinGW64 programs
accessible from anywhere and by any program running on the system.