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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: jack(at)jackkelly(dot)name, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #15525: Build failures when compiling Postgres with Make parallelization
Date: 2018-11-29 21:27:22
Message-ID: 4684.1543526842@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Andrew Gierth 2018-11-30 00:12:00 Re: BUG #15525: Build failures when compiling Postgres with Make parallelization
Previous Message Thomas Munro 2018-11-29 21:14:17 Re: BUG #15525: Build failures when compiling Postgres with Make parallelization