Re: BUG #15525: Build failures when compiling Postgres with Make parallelization

On Thu, Nov 29, 2018 at 3:32 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> ... and after contemplating my navel for awhile more, I believe
> I understand the problem.  APFS has sub-second file timestamp resolution,
> which doesn't seem to be exposed in Apple's version of "ls", but you can
> find it out from stat(2).  And what I'm seeing is that "ranlib" is
> truncating the timestamp of its output file to a one-second boundary:
>
> $ ls -ltr
> ...
> -rw-r--r--  1 tgl  admin   25888 Nov  2 11:37 interval.c
> -rw-r--r--  1 tgl  admin   20692 Nov  2 11:37 timestamp.c
> -rw-r--r--  1 tgl  admin  210640 Nov 28 21:04 libpgtypes.a
> -rw-r--r--  1 tgl  admin   43232 Nov 28 21:04 numeric.o
> -rw-r--r--  1 tgl  admin   18688 Nov 28 21:04 datetime.o
> -rw-r--r--  1 tgl  admin    5916 Nov 28 21:04 common.o
> -rw-r--r--  1 tgl  admin   76584 Nov 28 21:04 dt_common.o
> ...
>
> $ ~/a.out numeric.o
> mtime - Actual: 1543457047.155932
> atime - Actual: 1543457047.651358
> $ ~/a.out libpgtypes.a
> mtime - Actual: 1543457047.000000
> atime - Actual: 1543457047.000000

Nice detective work.  Possibly because libtool/ranlib whacks it with
utime(), which only knows about time_t, here:

https://github.com/opensource-apple/cctools/blob/master/misc/libtool.c#L2779

-- 
Thomas Munro
http://www.enterprisedb.com