ranlib on MacOS tries to be fancy with ctime/mtime and accidentally truncates them to 1s precision, causing the output file to be older than its inputs. Leading to parallel builds sometimes failing. Thanks, Apple! https://www.postgresql.org/message-id/28417.1543458718%40sss.pgh.pa.us … (and response)
-
Show this thread
-
>>> def test(): ... os.utime('test.a', None) ... t1 = os.stat('test.a').st_mtime ... os.system('ranlib test.a') ... t2 = os.stat('test.a').st_mtime ... return t2 - t1 ... >>> test() -0.8114330768585205 This Is Fine™
2 replies 4 retweets 8 likesShow this thread -
Replying to @delroth_
wouldn't this also happen anyway during leap second adjustments, assuming non-smeared time?
1 reply 0 retweets 0 likes -
Replying to @CounterPillow
Yes, it would, and that's one more argument in favor of smearing leap seconds until OSes get their shit together and use a monotonic representation of time instead of "approximate number of seconds since 1970".
2 replies 0 retweets 0 likes
But as it turns out leap seconds are fairly rare, running ranlib on APFS happens a few orders of magnitude more often :)
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.