URL: <http://savannah.gnu.org/bugs/?23210>
Summary: target/dependants with equal mtime Project: make Submitted by: None Submitted on: Thursday 05/08/2008 at 18:46 UTC Severity: 3 - Normal Item Group: Bug Status: None Privacy: Public Assigned to: None Open/Closed: Open Discussion Lock: Any Component Version: 3.81 Operating System: POSIX-Based Fixed Release: None _______________________________________________________ Details: Consider a set of Makefiles like the following: - - - - dir1/Makefile - - - - ../libfoo.a: foo1.o ar rcs ../libfoo.a foo1.o foo1.o: foo1.c cc -c foo1.c - - - - - - - - - - - - - - - - - - - - dir2/Makefile - - - - ../libfoo.a: foo2.o ar rcs ../libfoo.a foo2.o foo2.o: foo2.c cc -c foo2.c - - - - - - - - - - - - - - - - where a "make" is executed sequentially in the two directories. My expectation is that foo1.o will be built and ar'd into libfoo.a, then foo2.o will be built and also ar'd into libfoo.a. But what actually happens is that foo1.o is indeed built and ar'd into libfoo.a and foo2.o is also built, but then the date on libfoo.a is compared to the date on foo2.o and due to the coarse granularity of the mtime, foo2.o is observed to have the same date as libfoo.a rather than being newer, and it is not ar'd into libfoo.a. Is this a bug in make, or is the above example an illigitimate use of make? If it is considered a bug in make, here's a simpler more artificial example that demonstrates the same issue: - - - - Makefile - - - - a: b touch a b: touch b - - - - - - - - - - - - - And here is a command which demonstrates behavior I think is erroneous: % rm -f b ; touch a ; make a In this example I would expect it to see that "b" is not there, and determine that it must make "b" as well as update "a". Thus I expect to see output touch b touch a But instead on a system where the fstat gives an mtime with granularity in seconds which seems common, the above command usually results in only touch b being executed. Apparently it looks at the dependancy list for "a", decides it needs to make "b", does so, looks at the date on "b" after it has made it, then decides that since "b" is not strictly newer than "a" based on the date with 1-second granularity it won't update "a". _______________________________________________________ Reply to this item at: <http://savannah.gnu.org/bugs/?23210> _______________________________________________ Message sent via/by Savannah http://savannah.gnu.org/ _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make