GNU bug report logs - #45756
Prepending '+' to the recipe line when linking with GCC's -flto=jobserver

Previous Next

To reply to this bug, email your comments to 45756 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "R. Diez" <rdiezmail-temp2 <at> yahoo.de>
To: automake <at> gnu.org
Subject: Prepending '+' to the recipe line when linking with GCC's
 -flto=jobserver
Date: Tue, 18 Feb 2020 16:47:05 +0100

[Resending to bug-automake for tracking. --karl]

Hi all:

I am developing firmware similar to this one:

https://github.com/rdiez/JtagDue

First, I am building a GCC 8.3.0 cross-compiler toolchain for ARM
Cortex-M4F on Ubuntu 18.04.4 LTS, and I am then using it to build some
embedded software with a cross-compiling Autoconf project.

GCC introduced some time ago option -flto=jobserver in order to use the
GNU Make jobserver when parallelising LTO builds.

I am actually building many such Autoconf projects from a top-level
makefile, so using the top-level jobserver prevents overloading the
system with too many parallel jobs. That is what the jobserver was
designed for.

When doing a recursive make, you need to place a '+' character at the
beginning of the recipe line in order to let GNU Make pass the jobserver
file descriptors to the child processes. Alternatively, if you reference
variable $(MAKE) inside the recipe like, you get the same
effect. Otherwise, GNU Make does not let child processes inherit those
file descriptors (or so I heard, probably with "close fd on exec").

In my top-level makefile, I added those '+' prefixes manually, so all
Autoconf-generated makefiles are building in parallel but using the
top-level jobserver.

The trouble is, invoking GCC in the linking phase with -flto=jobserver
is actually a similar "recursive make" situation: GCC needs to inherit
those jobserver file descriptors.

However, Autoconf/Automake does not generate that '+' prefix for the
linking recipe.

Is there a way to overcome this limitation?

This will probably become a general issue in the future, as each stage
could theoretically benefit from multi-core CPUs. See for example:

https://gcc.gnu.org/wiki/ParallelGcc

Thanks in advance,
  rdiez

Message #8 received at 45756 <at> debbugs.gnu.org (full text, mbox):

From: "R. Diez" <rdiezmail-temp2 <at> yahoo.de>
To: 45756 <at> debbugs.gnu.org
Subject: Always prepend '+' to the recipe line
Date: Wed, 13 Jan 2021 13:15:03 +0100

This is not just an issue while linking. 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.

Beware that you cannot test this issue well with GCC at the moment, because GCC option -flto=jobserver will not issue any warning if the 
file descriptors are not available. I reported this a while ago, and it got fixed, but the target GCC version is 11, which has not been 
released yet:

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

Message #13 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "R. Diez" <rdiezmail-temp2 <at> yahoo.de>
To: Karl Berry <karl <at> freefriends.org>
Cc: automake <at> gnu.org
Subject: bug#45756: Prepending '+' to the recipe line when linking with GCC's
 -flto=jobserver
Date: Sat, 9 Jan 2021 18:30:02 +0100

[Resending in hopes it will attach to the new bug. --karl]

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

Message #16 received at 45756 <at> debbugs.gnu.org (full text, mbox):

From: Nick Bowler <nbowler <at> draconx.ca>
To: "R. Diez" <rdiezmail-temp2 <at> yahoo.de>
Cc: 45756 <at> debbugs.gnu.org, automake <at> gnu.org, Karl Berry <karl <at> freefriends.org>
Subject: Re: bug#45756: Prepending '+' to the recipe line when linking with
 GCC's -flto=jobserver
Date: Thu, 4 Feb 2021 18:12:26 -0500

On 2021-01-09, R. Diez <rdiezmail-temp2 <at> yahoo.de> wrote:
> [Resending in hopes it will attach to the new bug. --karl]
>
>> [...]
>> 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.

This issue has come up from time to time.  I think I wrote something on
it recently.  think everyone can agree that a solution to this problem
is desirable.

However simply prepending "+" to commands is not practical for Automake
to do because "+" has way more effects than just keeping the jobserver
fds open.  In particular, it will completely break "make -n".

A configure option to allow the user to enable this (rather than an
automake option) would probably be a simple and acceptable way to
get things at leas working, even if it's not an "ideal" solution.

Another possibility is for a "+"-prefixed command to check MAKEFLAGS
to see if options like -n that suppress command execution were used
(Automake already has to do this sort of thing in some rules).

Since I believe the jobserver feature is exclusive to GNU make, I
imagine it would also be possible to make use of GNU make substitution
features to only add the "+" when make options that suppress command
execution are omitted.  This could probably be done in a manner that is
interoperable with other make implementations and would likely perform
better than shell tests inside commands.

Finally this issue could also probably be solved by changing GNU make
itself: providing another mechanism to keep jobserver fds open in rules.

Cheers,
  Nick

Message #19 received at 45756 <at> debbugs.gnu.org (full text, mbox):

From: Karl Berry <karl <at> freefriends.org>
To: nbowler <at> draconx.ca, automake <at> gnu.org, 45756 <at> debbugs.gnu.org
Subject: Re: bug#45756: Prepending '+' to the recipe line when linking with
 GCC's -flto=jobserver
Date: Sat, 6 Feb 2021 15:37:33 -0700

Hi Nick - thanks for the reply on this. It all sounds sensible.

    Finally this issue could also probably be solved by changing GNU make
    itself: providing another mechanism to keep jobserver fds open in rules.

Clearly that would be great.

On the Automake side, I just don't have the desire to work on
this issue. I'm happy to apply a patch if you or anyone has a
reasonable improvement, but I'm not going to come up with it on my own,
unfortunately. --thanks, karl.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.