Correct usage of find_package(OpenSSL)

Usage
1

Hello,
we have multiplatform (Win/Mac/Lin) C++ project tree for building several executable binaries and shared libraries and we use cmake. I found in our code find_package(OpenSSL) in several CMakeLists.txt. Problem is that when more OpenSSL packages are installed then our code can mix link libraries and result build can have bad link dependencies. In our development cycle we can use as installed OpenSSL (for example in Win installed with *.msi) as our own OpenSSL builds copied to file system.
I tried to setup OPENSSL_ROOT_DIR in root CMakeLists.txt and it helps to find exactly OpenSSL package which I need but some child projects have found different package. I’d like to manage code to have only one place for find_package() for all project tree.

My question are:
Can I adjust our cmake code to use only one find_package(OpenSSL) in root CMakeLists.txt ? When I try this adjustment then it seems that information about found package in parent project branch is not inherited to child projects. How to correct it ? Or what do you recommend ?

Peter

2

Likely, yes.

What do you mean? You’ll also probably need to remove the other find_package(OpenSSL) calls as they may overwrite the top-level one.

3

Were you ever able to get this to work?

I am trying to install openssl libssl and libcrypto from our openssl installed into /opt.

I have to go thru contortions to get cmake to not use the os installed version as cmake findModule ignores the OPENSSL_ROOT_DIR and I have to use pkg_config.
I got the ldd output correct and everything works except the install bails saying :

CMake Error at {mydir}:
file Could not resolve runtime dependencies:

libcrypto.so.1.1