GNU bug report logs - #13107
timestamp bug when files are created just before make is run

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Mikulas Patocka <mikulas <at> artax.karlin.mff.cuni.cz>
Subject: bug#13107: closed (Re: bug#13107: timestamp bug when files are
 created just before make is run)
Date: Sun, 12 Jul 2020 01:24:02 +0000

[Message part 1 (text/plain, inline)]

Your bug report

#13107: timestamp bug when files are created just before make is run

which was filed against the automake package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to 13107 <at> debbugs.gnu.org.

-- 
13107: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13107
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Karl Berry <karl <at> freefriends.org>
To: 13107 <at> debbugs.gnu.org
Subject: Re: bug#13107: timestamp bug when files are created just before make
 is run
Date: Sat, 11 Jul 2020 19:23:45 -0600

Given the zero response, it seems undesirable to add even minor
complexity to support something which may no longer be needed.
Closing. -k

[Message part 3 (message/rfc822, inline)]

From: Mikulas Patocka <mikulas <at> artax.karlin.mff.cuni.cz>
To: bug-make <at> gnu.org, bug-automake <at> gnu.org
Subject: timestamp bug when files are created just before make is run
Date: Thu, 6 Dec 2012 23:02:48 +0100 (CET)

Hi

Try this Makefile:
---
a : b
        echo build a
        touch a

b : c
        echo build b
        touch b
---
and run this script:
touch b;sleep 1;touch a c;make

You see
"echo build b
build b
touch b"
but it doesn't remake a.

The apparent problem is that after make rebuilds b, it compares b's time 
with a's time, finds that the times are equal (because a was touched just 
before make was run) and doesn't rebuild a.

I think it is a bug - when b is finished, make should find out whether the 
rule for b modified the file b (if b's time is greater or equal than the 
time when the rule for b was started, then b may have been modified) and 
rebuild a in this case.

---

This bug is causing real-world problems in automake-generated Makefiles. 
This is a simplified piece of Makefile from automake:
all : config.h
        $(MAKE) all-am

config.h : stamp-h1
        echo build config.h

stamp-h1 : config.h.in
        echo build stamp-h1
        rm -f stamp-h1
        touch config.h
        touch stamp-h1

config.h.in : am__configure_deps
        echo build config.h.in
        rm -f stamp-h1
        touch config.h.in

all-am :
        echo ALL-AM

Now, if you run this script, you trigger the bug:

touch config.h.in;sleep 1;touch am__configure_deps;sleep 1;touch config.h stamp-h1;make

- you see "build config.h.in", but the other files are not rebuild and 
all-am is executed
(the essential thing to trigger the bug is that make is run in the same 
second in which config.h and stamp-h1 were created)


The problem that really happens in a real build:

* The user runs autoheader && aclocal && automake && autoconf && ./configure && make -j4
* Configure runs ./config.status, ./config.status writes config.h and 
stamp-h1
* Make sees that am__configure_deps is newer than config.h.in
* Make runs the rule for config.h.in. It sets the new timestamp for 
config.h.in and deletes stamp-h1
* Now make sees that config.h.in has the same time as stamp-h1 (the 
timestamp is read from make's cache even if stamp-h1 no longer exists)
* Because of the same timestamp, make doesn't run the commands for 
stamp-h1 and config.h
* Make executes a subprocess to build the rule all-am

* The subprocess doesn't have the file cache of the parent process, so the 
subprocess knows that stamp-h1 is missing
* The subprocess sees a dependency config.h->stamp-h1, stamp-h1 doesn't 
exist
* The subprocess executes the rule for stamp-h1 which regenerates config.h 
- the problem is that this rule is executed in parallel with other rules 
that build C files that include config.h - changing config.h while it is 
being used results in build failure

Another possible solution for this bug would be to remove rm -f stamp-h1 
from config.h.in rule, but there is some complex explanation in 
/usr/local/share/automake-1.12/am/remake-hdr.am why rm -f stamp-h1 is 
there so it would likely fix one bug and trigger another one.

So it would be better to fix this in make.

Mikulas

Previous Next

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