bugmake - Bugs: bug #23210, target/dependants with equal mtime

 
 

bug #23210: target/dependants with equal mtime

Submitter:  None
Submitted:  Thu 08 May 2008 06:46:35 PM UTC
   
 
Severity:  3 - Normal Item Group:  Bug
Status:  Not A Bug Privacy:  Public
Assigned to:  None Open/Closed:  Closed
Component Version:  3.81 Operating System:  POSIX-Based
Fixed Release:  None Triage Status:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 07 Jun 2009 02:02:40 AM UTC, comment #3: 

The problem is that the mtime of objects in an archive is based on the format of the archive.  There's not much we can do about this: it is what it is.  If the timestamp of the objects in the archive is 1 second granularity, then that's all we have.

Paul D. Smith <psmith>
Group administrator
Fri 09 May 2008 02:20:14 AM UTC, comment #2: 

I can see your point.  Your change essentially makes the target in the "target: source" rule more specific thus turning foo2.o into an exhaustive list of things the new more-specified target depends on.  Previously one Makefile said libfoo.a depends on foo1.o, and another said it depends on foo2.o, and that allowed the target to get updated before 100% of the things it depended on were created.

But I still find the behavior odd, because in the original example foo2.o is newer than libfoo.a for a reasonably intuitive sense of the word "newer": it was created chronologically after the most recent update to libfoo.a.  It's only the luck of how quickly the operations happen and the granularity of the filesystem's mtime that determines whether the second foo2.o will be ar'd or not.

I do like the facility you pointed out which allows a subset of an archive to be used as a target though, since it's quite natural to update an archive piecemeal and that wouldn't be possible without such a facility.  It seems like a pretty specialized solution, although I'll admit I'm not coming up with many other examples offhand where piecemeal updates are as common/natural as an archive (maybe a .tar file).

Anonymous
Thu 08 May 2008 07:17:25 PM UTC, comment #1: 

For this makefile:

> ../libfoo.a: foo1.o
>        ar rcs ../libfoo.a foo1.o


make is doing what you told it to; the problem is that the makefile doesn't capture your intent.  That makefile says "add or update the foo1.o member of ../libfoo.a if and_only_if the foo1.o file is newer than_the_archive_itself".  That's wrong: the foo1.o member should be updated if the foo1.o file is newer than the member_in_the_archive.  Using the archive member syntax solves that:

../libfoo.a(foo1.o): foo1.o
        ar rcs ../libfoo.a foo1.o

(Of course, archive members targets have their own issue with parallel builds, but that at least can be handled with .NOTPARALLEL)


Philip Guenther

Anonymous
Thu 08 May 2008 06:46:35 PM UTC, original submission:  

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".

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by psmith (Posted a comment)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2009-06-07 psmith StatusNone Not A Bug
        Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code