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

Andrew Gierth <andrew@tao11.riddles.org.uk>

From: Andrew Gierth <andrew@tao11.riddles.org.uk>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, jack@jackkelly.name, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2018-11-30T00:12:00Z
Lists: pgsql-bugs
>>>>> "Thomas" == Thomas Munro <thomas.munro@enterprisedb.com> writes:

 Thomas> But just for the record, while we're doing amateur software
 Thomas> archeology: I'm pretty sure Apple's libtool/ranlib is not
 Thomas> derived from BSD... it says it's from NeXT and has no
 Thomas> University of California copyright. They probably needed
 Thomas> something different to work with Mach-O objects, whereas
 Thomas> ancient BSD used a.out and modern BSDen use ELF. It also
 Thomas> supports their funky fat/universal libraries which NeXT and
 Thomas> Apple used to change CPU architectures several times
 Thomas> surprisingly smoothly. I don't see anything like that utime()
 Thomas> in either modern FreeBSD (where it's been rewritten at least
 Thomas> once) or ancient 4.4BSD lite sources.

I also noticed that an Apple manpage mentions that the linker at one
time compared the mod-time of the .a file with the embedded timestamp of
its archive symbol table member, which is probably why the utime() call
existed in the first place. I don't recall that behavior in other
linkers, offhand.

-- 
Andrew (irc:RhodiumToad)


Commits

  1. Ensure static libraries have correct mod time even if ranlib messes it up.