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

Previous Next

Package: automake;

Reported by: "R. Diez" <rdiezmail-temp2 <at> yahoo.de>

Date: Sun, 10 Jan 2021 06:27:02 UTC

Severity: normal

Tags: confirmed, help

Full log


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




This bug report was last modified 4 years and 128 days ago.

Previous Next


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