Re: BUG #15525: Build failures when compiling Postgres with Make parallelization - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #15525: Build failures when compiling Postgres with Make parallelization
Date
Msg-id 4684.1543526842@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #15525: Build failures when compiling Postgres with Make parallelization  (Thomas Munro <thomas.munro@enterprisedb.com>)
List pgsql-bugs
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


pgsql-bugs by date:

Previous
From: Thomas Munro
Date:
Subject: Re: BUG #15525: Build failures when compiling Postgres with Make parallelization
Next
From: Andrew Gierth
Date:
Subject: Re: BUG #15525: Build failures when compiling Postgres with Make parallelization