Closed iamnotacake closed 10 months ago
@Lagovas thoughts?
I'm waiting green tests) We discussed this in slack and @iamnotacake mentioned that this change brought more failures and he will debug it plus waiting the change of pr status to the ready for review
Previously we had broken BoringSSL build on macOS. Reason — include dir flags (
-I
) and lib search dir flags (-L
) were in wrong order.Then, discovered that
-L/usr/local/lib
is always before engine lib search path (stored inCRYPTO_ENGINE_LDFLAGS
). That caused OpenSSL 1.1 and OpenSSL 3 macOS CI builds to actually use system OpenSSL instead (seems like macOS has OpenSSL 3.0 in/usr/local/lib
).The final fix is:
-I$(PREFIX)/include
toCFLAGS
after engine CFLAGS are appended to CFLAGS-L$(PREFIX)/lib
to new macroADDITIONAL_LDFLAGS
LDFLAGS
is usedLDFLAGS
andCRYPTO_ENGINE_LDFLAGS
, thus make it lowest priorityIn process, extended Makefile with
VERBOSE
var. If set to anything, prints executed commands (compilation, linking) even for successfully completed commands. Because it's quite possible that a.c
file is successfully compiled with wrong flags, but then for some reason linking is failing. TL;DR is that it's useful. Also, after creation of Soter/Themis dynamic lib, print other dynamic libs it was linked with. So that we can clearly see in CI logs which OpenSSL lib is used in case of multiple ones exist in system like on macOS with Homebrew.This should fix the issue with macOS CI job.
During discussion we ended up with idea of additional macro, that it would be a more proper solution. Alternative possible solution with linker flags:
CRYPTO_ENGINE_LDFLAGS
beforeLDFLAGS
-L$(PREFIX)/lib
toLDFLAGS
ADDITIONAL_LDFLAGS
Checklist