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

On Fri, Nov 30, 2018 at 5:03 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Jack Kelly <jack(at)jackkelly(dot)name> writes:
> > Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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