Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 8993d3a

Browse files
committed
Ensure static libraries have correct mod time even if ranlib messes it up.
In at least Apple's version of ranlib, the output file is updated to have a mod time equal to the max of the timestamps of its components, and that data only has seconds precision. On a filesystem with sub-second file timestamp precision --- say, APFS --- this can result in the finished static library appearing older than its input files, which causes useless rebuilds and possible outright failures in parallel makes. We've only seen this reported in the field from people using Apple's ranlib with a non-Apple make, because Apple's make doesn't know about sub-second timestamps either so it doesn't decide rebuilds are needed. But Apple's ranlib presumably shares code with at least some BSDen, so it's not that unlikely that the same problem could arise elsewhere. To fix, just "touch" the output file after ranlib finishes. We seem to need this in only one place. There are other calls of ranlib in our makefiles, but they are working on intermediate files whose timestamps are not actually important, or else on an installed static library for which sub-second timestamp precision is unlikely to matter either. (Also, so far as I can tell, Apple's ranlib doesn't mess up the file timestamp in the latter usage anyhow.) In passing, change "ranlib" to "$(RANLIB)" in one place that was bypassing the make macro for no good reason. Per bug #15525 from Jack Kelly (via Alyssa Ross). Back-patch to all supported branches. Discussion: https://postgr.es/m/15525-a30da084f17a1faa@postgresql.org
1 parent 8340eba commit 8993d3a

File tree

1 file changed

+7
-1
lines changed

1 file changed

+7
-1
lines changed

src/Makefile.shlib

Lines changed: 7 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -300,11 +300,17 @@ all-static-lib: $(stlib)
300300

301301
all-shared-lib: $(shlib)
302302

303+
# In this rule, "touch $@" works around a problem on some platforms wherein
304+
# ranlib updates the library file's mod time with a value calculated to
305+
# seconds precision. If the filesystem has sub-second timestamps, this can
306+
# cause the library file to appear older than its input files, triggering
307+
# parallel-make problems.
303308
ifndef haslibarule
304309
$(stlib): $(OBJS) | $(SHLIB_PREREQS)
305310
rm -f $@
306311
$(LINK.static) $@ $^
307312
$(RANLIB) $@
313+
touch $@
308314
endif #haslibarule
309315

310316

@@ -472,7 +478,7 @@ install-lib-static: $(stlib) installdirs-lib
472478
$(INSTALL_STLIB) $< '$(DESTDIR)$(libdir)/$(stlib)'
473479
ifeq ($(PORTNAME), darwin)
474480
cd '$(DESTDIR)$(libdir)' && \
475-
ranlib $(stlib)
481+
$(RANLIB) $(stlib)
476482
endif
477483

478484
install-lib-shared: $(shlib) installdirs-lib

0 commit comments

Comments
 (0)