This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [Gold] Skip linking when output file is newer than all inputs?
- From: John Reiser <jreiser at bitwagon dot com>
- To: binutils at sourceware dot org
- Date: Tue, 02 Jul 2013 14:00:54 -0700
- Subject: Re: [Gold] Skip linking when output file is newer than all inputs?
- References: <51BB004B dot 8050200 at nh2 dot me> <CAKOQZ8zpxoRrc0_Cv59o7UUnbMsjWX3Cmg8teMApVqxcJEpVWA at mail dot gmail dot com> <51BB23C9 dot 4050403 at nh2 dot me> <51D3012C dot 2070603 at nh2 dot me>
On 07/02/2013 09:34 AM, Niklas HambÃchen wrote:
> It would be nice to get an answer to this.
>
> On 14/06/13 07:08, Niklas HambÃchen wrote:
>>> If I understand you correctly, that's what the make program is for. I
>>> don't think gold needs to have the same functionality.
>>
>> That's not what I meant, in a Makefile you usually have no way to
>> actually depend on a big number of ld inputs - for example when they are
>> in system paths and you reference them by name (e.g. -l...); the logic
>> to select from these paths is inside the linker program.
I suggest that the linker should not implement the requested 'make'-like feature
of skipping linking when the output file already exists and is newer than all inputs.
Use 'make' for that. Instead what the linker should do is generate the list
of files which contribute to the output, so that the user can construct the
list of predecessors reliably when using 'make'.
But wait, the linker already does that! Use the --cref option, plus simple post-
processing similar to "awk {print $2} | sort --unique". (Or, generate a map
using -M or -Map=<file>, then process the map.) Yes, this is a two-pass process,
much like using the -M... options to gcc to generate the list of files which
the preprocessor accesses while expanding the input. But using the requested
linker feature needs the output file to exist anyway. The output file must have
been created by a previous invocation of the linker, so two passes are OK--
unless the "recipe" changes. But if the recipe changes then in practice
idempotency is suspect anyway. [Think carefully about what this implies:
the logic behind the original request is *not* always valid!] Also, if 'gold'
takes 500ms (0.5s) then 'make' may well take even longer, so be happy
for the existing "shortcut".