Re: MSYS2 PATH problems with native compilation

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

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.

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

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

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. Furthermore, those executables might
need other files present, that scenario is best described as "can of
worms".

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

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.

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

> 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. However, I'm proposing to set
PATH transiently, see 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.
>
> 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.

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

In MSYS2/Mingw-w64 it is quite common.

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

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.