Re: Enabling the jobserver

[Eli Zaretskii]

> From: Richard Copley <rcopley@gmail.com>
> Date: Tue, 11 Jun 2024 09:30:13 +0100
> Cc: psmith@gnu.org, help-make@gnu.org
> 
> On Tue, 11 Jun 2024 at 07:31, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Just curious: why does GCC need to know about Make's jobserver?
> > (Since you say "GCC source", I presume you are not talking about the
> > GCC build scripts, but GCC itself.)
> 
> Its link-time optimization has some jobs to perform in parallel, and
> attempts to do so by writing out a makefile and executing the program
> named in the environment variable "MAKE" (or by executing "make", if
> none). At the linking stage, when using link-time optimization, one
> often gets the following message:
> 
> lto-wrapper.exe: warning: using serial compilation of 2 LTRANS jobs
> lto-wrapper.exe: note: see the '-flto' option documentation for more 
> information
> 
> The "-flto" documentation does not directly explain the error or what
> to do about it, so one has a fun puzzle. (Or one can ignore the
> warning, as I have been doing for many years already. It doesn't do
> any harm.)
> 
> Passing "-flto=jobserver" does not work, in the first instance because
> the "--jobserver-auth=" argument in MAKEARGS is overvalidated. GCC
> ignores it (and removes it from MAKEARGS) unless it is a pair of
> numbers or contains "fifo:".
> 
> But passing "-flto=n" (where n is a number which should be used as the
> argument to the "-j" option in the inferior make) does not work
> either.
> 
> One can set "export MAKE:=$(MAKE)" in a target-specific variable in
> the top-level makefile to pass "mingw32-make" (the installed name of
> native Windows GNU Make in its MSYS2 package) through to GCC, and then
> GCC creates a temporary makefile and executes "mingw32-make", but an
> error message is printed:
> 
> The system cannot find the path specified.
> mingw32-make[1]: [C:\Users\buster\AppData\Local\Temp\cc4moXuq.mk:3:
> C:\Users\buster\AppData\Local\Temp\ccCEYc1I.ltrans0.ltrans.o] Error 1
> (ignored)
> 
> The file that could not be found is presumably
> "$(prefix)/lib/gcc/x86_64-w64-mingw32/14.1.0/collect2.exe" (another
> layer of wrapping for the linker). I don't know why it isn't found.
> Perhaps it is not on the path. By this time the temporary makefile has
> been deleted, and for now, I have lost the motivation to debug
> further.

Thanks.  I wonder how they distinguish between MinGW (a.k.a. "native")
port of GNU Make, and MSYS/Cygwin ports.  The latter implement the
jobserver and the associated command-line arguments as on Unix.
Distinguishing only by name is dangerous: the MinGW port of Make on my
system is called "make.exe", not "mingw32-make.exe" (and that's what
people who install from ezwinports site get).  There's a way to detect
the kind of the executable reliably (Emacs implements it, see
w32-application-type), but it's not entirely trivial.

But this quickly becomes way out off-topic here, I guess.