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

On Fri, Nov 30, 2018 at 5:03 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jack Kelly <jack@jackkelly.name> writes:
> > Thomas Munro <thomas.munro@enterprisedb.com> writes:
> >> As for what could be done about it, it seems like we (or the Nix
> >> project, in a local patch) could declare individual targets to have
> >> .LOW_RESOLUTION_TIME:
> >> https://www.gnu.org/software/make/manual/html_node/Special-Targets.html
> >> That doesn't seem any better than using "touch" to make a better mtime
> >> though.
>
> In fact it's worse, because it opens you up to the same problems that
> sub-second timestamps were meant to fix.
>
> After sleeping on this, I'm liking the idea of adding "touch" to our
> rule better.  We shouldn't imagine that this problem exists in a vacuum:
> Apple got that ranlib code from some BSD or other, so it probably
> exists in similar form elsewhere.  And filesystems with sub-second
> timestamps are getting more common.  So it seems likely that this issue
> could manifest on other combinations than the one we see here.

+1 for that solution (which I see you've just pushed).

But just for the record, while we're doing amateur software
archeology:  I'm pretty sure Apple's libtool/ranlib is not derived
from BSD... it says it's from NeXT and has no University of California
copyright.  They probably needed something different to work with
Mach-O objects, whereas ancient BSD used a.out and modern BSDen use
ELF.  It also supports their funky fat/universal libraries which NeXT
and Apple used to change CPU architectures several times surprisingly
smoothly.  I don't see anything like that utime() in either modern
FreeBSD (where it's been rewritten at least once) or ancient 4.4BSD
lite sources.

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