Link to libcrypto and libssl dynamically when using SYSTEM_LIBCRYPTO #5312
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When using SYSTEM_LIBCRYPTO, the cmake build system attempts to link libssl statically and libcrypto dynamically. This leads to missing symbols as openssl expects either both libraries to be linked statically or dynamically, not one or the other
Fixes #5210
Description
#5210 reported an issue in which, when using the cmake build infrastructure directly, missing symbols were found when loaded (most notably ossl_time_now). This occured because libssl is being linked statically (which references ossl_time_now in the static archive), but ossl_time_now is only defined as an internal symbol in the libcrypto.dso.
Testing
Unsure, I think most of the tests use the powershell build scripts to build (which link libssl and libcrypto statically avoiding the problem). presumably we would want to test cmake directly, but I'm not sure if thats worthwhile
Documentation
No