While there are crypto libraries, there is no crypto include, only a
global include.
This avoid having OSX to fail finding the symbol when openssl is
installed via Homebrew.
Details
- Reviewers
deadalnix jasonbcox - Group Reviewers
Restricted Project - Commits
- rSTAGINGd74f5fd37e6e: [CMAKE] Fix wrong Openssl include directory variable name
rABCd74f5fd37e6e: [CMAKE] Fix wrong Openssl include directory variable name
On OSX Catalina, with openssl installed via Homebrew as per the build-osx.md documentation:
mkdir buildcmake && cd buildcmake cmake -GNinja ..
Check in the output that the EVP_MD_CTX_new symbol is found.
Diff Detail
- Repository
- rABC Bitcoin ABC
- Branch
- cmake_fix_openssl_include_dir
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 8573 Build 15136: Default Diff Build & Tests Build 15135: arc lint + arc unit
Event Timeline
IMO the test plan is lacking. Some thoughts:
- I happen to know that the CI was ported over to CMake recently, so we know the current build isn't broken, but this should be explicitly tested regardless.
- A runnable test plan would be nice for those that have OSX.
@jasonbcox I updated the test plan to use runnable commands.
Since the openssl library is in the search path for all the other builds, the issue only happen to cause trouble on OSX.
Furthermore if the symbol is not found (under normal circumstances, because it is really not part of the header), it is handled in the code and won't cause any trouble.
This exact behavior is not easily testable on CI, as it would require to have an OSX agent.
What can be possibly done is to compare the Cmake cache values with the expected values for our agents, but this makes the test be hardware + OS + installation dependent.