Re: Prepending '+' to the recipe line when linking with GCC's -flto=jobserver

[R. Diez]

> [...]
> At any rate, it would be extremely helpful to have a minimal-as-possible
> runnable (automake-able) example showing the case where the + needs to
> be prepended. rdiez, can you create such a mini-project?
> [...]

I normally use Autoconf, and I do not understand very much the separation between Autoconf and Automake. I do not know who is responsible for the 
generation of the makefile rules to link the executable. Either Autoconf or Automake must decide that GCC is not just used for compiling each object 
file, but also for linking, and that rule is not visible in the makefile.am file.

Of course, such a linking rule does not user $(MAKE), and there is no '+' prefix, so the GNU Make jobserver file descriptors will not be passed to 
child processes. This is documented in the GNU Make manual.

You do not need any special demo project for this. Just take any existing Automake project written in C or C++, and use these compilation flags in 
configure.ac :

AM_CFLAGS="-flto=jobserver"
AM_CXXFLAGS="-flto=jobserver"

If you run the makefile with "make -j 2", GCC will receive environment variable MAKEFLAGS with a setting like "--jobserver-fds=xxx", but GNU Make will 
close the file descriptors mentioned there before executing the rule and running GCC. This issue is not visible in GCC yet due to this bug I reported:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94330

I am not sure how I can demonstrate this in a project, there is not actually 
much to demonstrate.

This is not just an issue while linking. Like I said, any stage, including compilation of a single object file, could use the GNU Make jobs server. So 
there should be a global option in Autoconf or Automake to prepend a '+' to all generated rules.

In fact, you would have thought that this should be the default, because any tool, at any stage, could decide in the future to go multithread, and 
there is no reason to ignore an existing GNU Make job server to limit the overall system load.

Regards,
  rdiez