Change priority of PREFIX in CFLAGS and LDFLAGS

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 in CRYPTO_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:

Append -I$(PREFIX)/include to CFLAGS after engine CFLAGS are appended to CFLAGS
Append -L$(PREFIX)/lib to new macro ADDITIONAL_LDFLAGS
- Put this new macro where LDFLAGS is used
- Put it after both LDFLAGS and CRYPTO_ENGINE_LDFLAGS, thus make it lowest priority

In 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:

Put CRYPTO_ENGINE_LDFLAGS before LDFLAGS
Append -L$(PREFIX)/lib to LDFLAGS
Remove ADDITIONAL_LDFLAGS

Checklist

[x] Change is covered by automated tests
[x] ~Benchmark results are attached (if applicable)~
[x] The coding guidelines are followed
[x] ~Public API has proper documentation~
[x] ~Example projects and code samples are up-to-date (in case of API changes)~
[x] ~Changelog is updated (in case of notable or breaking changes)~

cossacklabs / themis

Change priority of PREFIX in CFLAGS and LDFLAGS #1031

Checklist