mirror of
https://github.com/darlinghq/cctools-port.git
synced 2024-11-27 06:00:31 +00:00
17c2bf9247
When finalizing an archive, ranlib performs the following operations: 1. stat to obtain the current mtime (pre-write mtime) 2. rewrite the timestamp in the archive header 3. utime to restore the pre-write mtime Unfortunately, utime only supports a 1s resolution. This means that on systems with sub-second filesystem timestamps resolution (one notable example being APFS), the following sequence of events can happen: 1. stat to obtain the current mtime (pre-write mtime) returns hh:mm:ss.123 2. rewrite the timestamp in the archive header 3. utime to restore the pre-write mtime ends up restoring hh:mm:ss.000. This can cause ranlib to roll back the mtime of an archive in the past instead of moving it into the future. Given that "make" heavily relies on filesystem timestamps to determine dependencies and required rebuilds, this can lead to many problems. This was discovered because it caused random failures when parallel building postgresql. To address the issue, we attempt to use utimensat if available. This is checked via autoconf, but on macOS this is not enough: utimensat can be present at compile time without being available at link time, and it was only added very recently (10.13). Inspired by how CPython is handling this, we use #pragma weak to make the runtime dependency optional. |
||
|---|---|---|
| .. | ||
| ar | ||
| as | ||
| cbtlibs | ||
| efitools | ||
| gprof | ||
| include | ||
| ld64 | ||
| libobjc2 | ||
| libstuff | ||
| m4 | ||
| man | ||
| misc | ||
| otool | ||
| APPLE_LICENSE | ||
| AUTHORS | ||
| autogen.sh | ||
| cctools-ld64.workspace | ||
| cctools.project | ||
| ChangeLog | ||
| compile | ||
| config.guess | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| install-sh | ||
| ld64.project | ||
| ltmain.sh | ||
| Makefile.am | ||
| Makefile.in | ||
| missing | ||
| NEWS | ||
| README | ||