From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@enterprisedb.com>
cc: jack@jackkelly.name,
        PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15525: Build failures when compiling Postgres with Make
 parallelization
In-reply-to: 
 <CAEepm=2X9pKPN_8uKhqOPApb7Y5_XVNON5P49Tz8Fhx5fdiSQw@mail.gmail.com>
References: <15525-a30da084f17a1faa@postgresql.org>
 <31602.1543363896@sss.pgh.pa.us> <87k1kwlvad.fsf@jackkelly.name>
 <28417.1543458718@sss.pgh.pa.us>
 <CAEepm=3wHjf9ZfekMq5x0qs_r1XBd0YXTrhoZMbmDx-xE8NXwA@mail.gmail.com>
 <31059.1543461919@sss.pgh.pa.us>
 <CAEepm=3WXu0Ke8AB3i9Z8EdKZ_RajcKrkwj1GTkgcdqdaafjqw@mail.gmail.com>
 <87r2f4jfu0.fsf@jackkelly.name> <28445.1543507385@sss.pgh.pa.us>
 <CAEepm=2X9pKPN_8uKhqOPApb7Y5_XVNON5P49Tz8Fhx5fdiSQw@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@enterprisedb.com>
	message dated "Fri, 30 Nov 2018 10:14:17 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4683.1543526842.1@sss.pgh.pa.us>
Date: Thu, 29 Nov 2018 16:27:22 -0500
Message-ID: <4684.1543526842@sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@enterprisedb.com> writes:
> 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.

Interesting.  There's definitely some funky behavior in Apple's ranlib.
While testing this, I noted that sometimes it will produce a timestamp
that seems to be max-of-the-input-timestamps (truncated to seconds),
which can be much older than current time.  Other times it will produce
current time (truncated to seconds).  No idea what's causing this
difference in behavior.

			regards, tom lane