Re: BUG #15525: Build failures when compiling Postgres with Make parallelization
Tom Lane <tgl@sss.pgh.pa.us>
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>
Date: 2018-11-29T21:27:22Z
Lists: 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
Commits
-
Ensure static libraries have correct mod time even if ranlib messes it up.
- fe6ad3bd2c5c 9.5.16 landed
- bac66c6e7cf3 10.7 landed
- 8993d3a10d13 9.6.12 landed
- 826eff57c4c2 12.0 landed
- 0ff56de46eb0 11.2 landed
- 02d310471365 9.4.21 landed