oqs-provider: MacOS: fails to find liboqs

Describe the bug Tests should - but do not - look in /opt/local/lib for libraries like liboqs.dylib.

LD_LIBRARY_PATH=/Users/ur20980/src/oqs-provider/.local/lib64
OPENSSL_APP=/opt/local/libexec/openssl3/bin/openssl
OPENSSL_CONF=/opt/local/libexec/openssl3/etc/openssl/openssl.cnf
OPENSSL_MODULES=/opt/local/libexec/openssl3/lib/ossl-modules
Version information:
OpenSSL 3.1.0 14 Mar 2023 (Library: OpenSSL 3.1.0 14 Mar 2023)
list: unable to load provider oqsprovider
Hint: use -provider-path option or OPENSSL_MODULES environment variable.
40664950F87F0000:error:12800067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:118:filename(_build/lib/oqsprovider.dylib): dlopen(_build/lib/oqsprovider.dylib, 0x0002): Library not loaded: @rpath/liboqs.3.dylib
  Referenced from: <DE45930A-2ABF-3032-BFF3-19F96D0064A6> /Users/ur20980/src/oqs-provider/_build/lib/oqsprovider.0.5.0-dev.dylib
  Reason: tried: '/usr/local/lib/liboqs.3.dylib' (no such file), '/usr/lib/liboqs.3.dylib' (no such file, not in dyld cache)
40664950F87F0000:error:12800067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:152:
40664950F87F0000:error:07880025:common libcrypto routines:provider_init:reason(524325):crypto/provider_core.c:904:name=oqsprovider
Baseline openssl invocation failed. Exiting test.

LD_LIBRARY_PATH is not an answer, because (a) MacOS uses DYLD_LIBRARY_PATH and ignores LD_LIBRARY_PATH, and (b) setting that env var would limit where the loader searches for missing libraries, i.e., we’d risk that it would now find what’s in $DYLD_LIBRARY_PATH but stops finding what’s not there.

To Reproduce See above.

Expected behavior Tests passing, with all the relevant libraries located correctly.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please complete the following information):

OS: MacOS Ventura 13.4
OpenSSL version: 3.2.0-dev and 3.1.0

About this issue

Original URL
State: closed
Created a year ago
Comments: 21 (20 by maintainers)

Most upvoted comments

my bigger concern is that DYLD_LIBRARY_PATH does not seem to be inherited by the scripts/runtests.sh

I’m not sure I understand what is meant by “inherited by”?

But whatever, I think I now found a resolution: By passing to the cmake invocation for oqsprovider the environment variable liboqs_DIR one can direct it to properly create a reference to wherever liboqs has been placed: https://github.com/open-quantum-safe/oqs-provider/blob/2ba86da572e9ad55d3f23765f8c784036413606f/.circleci/config.yml#LL140C1-L140C22. This does not work when using -DCMAKE_PREFIX_PATH (but then again, this is logical as only the former is meant to locate external libraries while the latter defines the install location – my mistake was to place liboqs and openssl into the same place which caused the problem to be hidden in the original install scripts). After adapting this in the CI instructions, everything works as desired, regardless where (a shared) liboqs has been installed (both positively and negatively tested on an M1 OSX box).

The reason why things fail for you most likely have to do with the way you build liboqs: Your script explicitly passes “CMAKE_C_FLAGS” but no matching instructions for the linker. The approach of using cmake mechanisms by way of directing oqsproviders cmake to the install location of liboqs using the liboqs_DIR environment variable directive seems to resolve this, both for include/compile as well as linking instructions.

Thanks for making me learn quite a bit about OSX, shared libs and installs and cmake: This definitely improved how things can be (separately) deployed – and now also tested – it just was tedious to do this so “remotely”…

baentsch on May 31, 2023