A clean parallel world build can fail because the OpenSSL engine subdirectories attempt to link before the parent libcrypto shared library exists.
Reproduction:
env MAKEOBJDIRPREFIX=/tmp/pr500-obj make -j10 buildworld buildkernel
Observed failures:
--- all_subdir_secure/lib/libcrypto/engines/capi ---
ld: error: unable to find library -lcrypto
cc: error: linker command failed with exit code 1
*** [capi.so.full] Error code 1
--- all_subdir_secure/lib/libcrypto/engines/padlock ---
ld: error: unable to find library -lcrypto
cc: error: linker command failed with exit code 1
*** [padlock.so.full] Error code 1
At failure time neither the parent object directory nor the staged sysroot contained libcrypto.so. secure/lib/libcrypto/Makefile declares SUBDIR=engines, while secure/lib/libcrypto/engines/Makefile declares SUBDIR_PARALLEL=. The capi and padlock engine Makefiles use bsd.lib.mk and link against -lcrypto, but the build graph does not ensure that the parent library is available before those parallel links.
An incremental rerun may get past the failure after enough parent-library objects have been retained, which makes this timing-dependent and easy to miss. The dependency/order should be expressed explicitly so a clean -j build succeeds on the first invocation.
This was discovered while validating PR #500, but the PR does not modify the engine Makefiles or their subdirectory ordering.
A clean parallel world build can fail because the OpenSSL engine subdirectories attempt to link before the parent libcrypto shared library exists.
Reproduction:
Observed failures:
At failure time neither the parent object directory nor the staged sysroot contained
libcrypto.so.secure/lib/libcrypto/MakefiledeclaresSUBDIR=engines, whilesecure/lib/libcrypto/engines/MakefiledeclaresSUBDIR_PARALLEL=. The capi and padlock engine Makefiles usebsd.lib.mkand link against-lcrypto, but the build graph does not ensure that the parent library is available before those parallel links.An incremental rerun may get past the failure after enough parent-library objects have been retained, which makes this timing-dependent and easy to miss. The dependency/order should be expressed explicitly so a clean
-jbuild succeeds on the first invocation.This was discovered while validating PR #500, but the PR does not modify the engine Makefiles or their subdirectory ordering.