Conversation
|
@rajesh-gali had issues building and found this was the reason in his scenario. |
d81c48b to
0ea2e69
Compare
| # 3. Build the provider with static OpenSSL | ||
| OPENSSL_DIR=/opt/openssl-static OPENSSL_STATIC=1 \ | ||
| cargo build -p azihsm_ossl_provider --features mock |
There was a problem hiding this comment.
The new step text says the provider is built “with static OpenSSL”, but the build system for the provider uses CMake find_package(OpenSSL 3 REQUIRED) and links ${OPENSSL_CRYPTO_LIBRARY}. The OPENSSL_DIR/OPENSSL_STATIC environment variables set here won’t affect CMake’s OpenSSL selection (they’re for openssl-sys), so as written this is misleading and may confuse readers about what is actually static vs dynamic. Consider either (a) rewording step 3 to clarify the env vars are to ensure azihsm_api_native (built via Corrosion) links statically, while the provider uses the system OpenSSL, or (b) if the provider truly must link to the static OpenSSL, pass the appropriate CMake variables (e.g., OPENSSL_ROOT_DIR / OPENSSL_USE_STATIC_LIBS) and update the instructions accordingly.
|
I'm a bit confused that this resolves it. The reason we built the library against the static OpenSSL is that we want to resolve the circular dependency (OpenSSL -> Provider -> Library -> OpenSSL -> Provider -> ... ). Building the provider against static OpenSSL will also work - not sure what issue it solves for @rajesh-gali . @rajesh-gali : Can you give me more details on the error that you saw? I never had to do this and I use Dockerfile's that also do not build the provider against static OpenSSL and everything works fine. |
|
We should also update the OpenSSL version number
to 3.0.3 |
Signed-off-by: Jens Topp <jens.topp@9elements.com>
|
Also add a section on how to run the integration tests locally |
No description provided.