14

My project uses CMake to build, but uses the local macOS version of clang and ld when building on a Mac.

After upgrading to Xcode 11 on macOS 10.15 Catalina, I'm unable to link with the following error: ld: cannot link directly with dylib/framework, your binary is not an allowed client of /usr/lib/libcrypto.dylib for architecture x86_64.

Is this related to the new app notarizing? Is there a fix that doesn't require the project being in Xcode (I use CLion to develop on macOS) or doesn't require linking my own build of OpenSSL?

Any help appreciated.

Didier Malenfant
  • 729
  • 1
  • 10
  • 25
  • It looks like the twitter-verse mentions that this is 'normal'. Basically the version included was outdated so now they just prevent you from linking to it. Can anyone confirm or deny semi-officially? https://twitter.com/steipete/status/1168926846962020352 – Didier Malenfant Oct 18 '19 at 14:51
  • Running into this issue this morning myself and digging around, I came across this Apple forum message that indicates that Apple intends these types of libraries to be used only internally. The advice is to build third-party libraries yourself and include them with your application. https://forums.developer.apple.com/thread/124782 – Casey Oct 30 '19 at 18:51
  • 1
    @casey I think that's the correct answer, as I suspected when I found the twitter post. Do you want to post this as an answer and I'll approve it? – Didier Malenfant Oct 31 '19 at 10:51
  • for cmake, which picks an external openssl on mac osx (say via vscode), we need to include both: OpenSSL::SSL as well as OpenSSL::Crypto in the TARGET_LINK_LIBRARIES stanza. Listing just OpenSSL:SSL would pick the ssl part from vscode build but would again try to to use the system provided libcrypto.dylib – Neelabh Mam Sep 19 '21 at 15:51

4 Answers4

13

As the FindOpenSSL.cmake code looks for the libraries and then stores the result in the CMake cache, you can forcefully set the path before you try to find OpenSSL. The FindOpenSSL.cmake code will not replace your path.

if (APPLE)
    # This is a bug in CMake that causes it to prefer the system version over
    # the one in the specified ROOT folder.
    set(OPENSSL_ROOT_DIR ${OPENSSL_ROOT_DIR} /usr/local/Cellar/openssl@1.1/1.1.1g/)
    set(OPENSSL_CRYPTO_LIBRARY ${OPENSSL_ROOT_DIR}/lib/libcrypto.dylib CACHE FILEPATH "" FORCE)
    set(OPENSSL_SSL_LIBRARY ${OPENSSL_ROOT_DIR}/lib/libssl.dylib CACHE FILEPATH "" FORCE)
endif()
find_package(OpenSSL REQUIRED)

Make sure you clear the CMake cache, because once the library is found with the wrong path, this hack won't fix it, even if you rerun CMake on your project.

Martijn Courteaux
  • 67,591
  • 47
  • 198
  • 287
5

I have installed OpenSSL from brew, and find_package seems to detect the brew version, but it tries to link link the project with the OpenSSL installed in the system, which is LibreSSL.

I tried to force the find_package to set the exact path of the library, but it does nothing:

if(APPLE)
    set(OPENSSL_ROOT_DIR /usr/local/Cellar/openssl@1.1/1.1.1d/)
endif()

So I ended up by setting the dependencies manually, which it is not ideal but it works in the meantime for development.

# OpenSSL
find_package(OpenSSL REQUIRED)
if(OPENSSL_FOUND)
    if(APPLE)
        include_directories(/usr/local/Cellar/openssl@1.1/1.1.1d/include)
        list(APPEND LIB_LIST /usr/local/Cellar/openssl@1.1/1.1.1d/lib/libssl.dylib)
        list(APPEND LIB_LIST /usr/local/Cellar/openssl@1.1/1.1.1d/lib/libcrypto.dylib)
        message(STATUS "OpenSSL Version: ${OPENSSL_VERSION} ${OPENSSL_INCLUDE_DIR} ${OPENSSL_LIBRARIES}")
    else()
        include_directories(${OPENSSL_INCLUDE_DIR})
        list(APPEND LIB_LIST ${OPENSSL_LIBRARIES})
        message(STATUS "OpenSSL Version: ${OPENSSL_VERSION} ${OPENSSL_INCLUDE_DIR} ${OPENSSL_LIBRARIES}")
    endif()
endif()

The Cmake Output provides this information, where it detects the OpenSSL library from brew, but links with the system library. Not sure why.

-- OpenSSL Version: 1.1.1d /usr/local/Cellar/openssl@1.1/1.1.1d/include /usr/lib/libssl.dylib;/usr/lib/libcrypto.dylib

Hope this help!

Alvaro Luis Bustamante
  • 8,157
  • 3
  • 28
  • 42
1

Running into this issue this morning myself and digging around, I came across this Apple forum message that indicates that Apple intends these types of libraries to be used only internally. The advice is to build third-party libraries yourself and include them with your application.

Casey
  • 12,070
  • 18
  • 71
  • 107
0

i had this problem before. solution :- go build folder:

$ rm -rf *
$ cmake -DOPENSSL_ROOT_DIR="/usr/local/opt/openssl@1.1" ..
$ cmake -DOPENSSL_LIBRARIES="/usr/local/opt/openssl@1.1/lib" ..
$ make
Abdullah Hassan
  • 178
  • 2
  • 10