[Solved] C++ OpenSSL-1.0 compatibility

sum01 · 2017-07-13 16:44:26

I need to fix how a header file looks for OpenSSL. In the Cmake fork I've made, the compatibility flag and module I created do work to get the correct paths, but the header file ignores them.

Links:
Original repo https://github.com/openvcash/vcash
My fork https://github.com/sum01/vcash/tree/add … nd-cleanup

Original post here

sum01 wrote:

So yes, boost-build did get me past the previous issues, but of course I ran into all the broken Jamfile's. I gave up and moved on to creating a cmake fork. https://github.com/sum01/vcash/tree/add … nd-cleanup
It builds/works on Ubuntu, but I'm having issues getting it to work with OpenSSL on Arch.
I tried to get around this by making a Find module to get OpenSSL-1.0 libs and paths https://github.com/sum01/vcash/blob/add … ts.txt#L50, which it does get the paths, but it seems that https://github.com/sum01/vcash/blob/add … er.hpp#L29 is ignoring my paths provided by the custom find module.
Anyone know how to actually get it to use the OpenSSL-1.0 paths/libs?
EDIT: Maybe this is more a question for the programming thread. I'll move over there.

EDIT2: Solved my problem with a custom flag and the OPENSSL_ROOT_DIR flag.

This gets added into CMakeLists.txt anywhere before the find_package(OpenSSL)

option(CUSTOM_OPENSSL_LIBDIR "Explain this flag here, or don't I don't care." OFF)
IF(OPENSSL_ROOT_DIR AND CUSTOM_OPENSSL_LIBDIR)
  list(APPEND OPENSSL_ROOT_DIR "${CUSTOM_OPENSSL_LIBDIR}")
ENDIF()

cmake -DOPENSSL_ROOT_DIR="/usr/include/openssl-1.0" -DCUSTOM_OPENSSL_LIBDIR="/usr/lib/openssl-1.0"

This builds correctly, although strangely enough when I run namcap on the pkg, it complains about an Insecure RPath that's empty. Oh well..

E: Insecure RPATH '' in file ('vcash/vcashd')

EDIT3: https://www.archlinux.org/todo/openssl-110-rebuild/ contains the "correct" flags, although they still build with an insecure rpath, so I guess not much can be done about that.
EDIT4: THE ACTUAL FIX WITH NO INSECURE RPATH

cmake -DOPENSSL_INCLUDE_DIR=/usr/include/openssl-1.0 -DOPENSSL_SSL_LIBRARY=/usr/lib/libssl.so.1.0.0 -DOPENSSL_CRYPTO_LIBRARY=/usr/lib/libcrypto.so.1.0.0

Last edited by sum01 (2017-07-21 17:21:38)

The Infinity · 2017-07-13 22:33:29

I had recently a similar problem. My application still had to use legacy OpenSSL when cross-compiling with mingw-w64 because I want it to link statically against Qt 5 which does not support OpenSSL >= 1.1 yet.

I chose the (in my opinion) simplest solution: Just allow the user/packager who builds the application to override the auto-detected paths for the OpenSSL library and header files by adding cache variables for them. This should allow compiling the application under any platform, independently whether CMake is able to find the right OpenSSL on its own or not.

> but it seems that https://github.com/sum01/vcash/blob/add … er.hpp#L29 is ignoring my paths provided by the custom find module

Include dirs have to be set manually, eg. via target_include_directories(). Just calling find_package is not sufficient. So maybe the project doesn't do that and hence the include path provided by your CMake package is unused?

Last edited by The Infinity (2017-07-13 22:34:10)

sum01 · 2017-07-14 06:08:46

So if I'm understanding this correctly, instead of doing..

include_directories(
    ${CMAKE_CURRENT_SOURCE_DIR}/coin/include
    ${CMAKE_CURRENT_SOURCE_DIR}/database/include
    ${Boost_INCLUDE_DIRS}
    ${OPENSSL_INCLUDE_DIR}
    ${BERKELEYDB_INCLUDE_DIRS}
    )

  add_library(coin ${SOURCES})
  add_library(database ${DATABASE_SOURCES})

I would do..

  add_library(coin ${SOURCES})
  add_library(database ${DATABASE_SOURCES})
  target_include_directories(coin PUBLIC ${Boost_INCLUDE_DIRS} ${OPENSSL_INCLUDE_DIR} ${BERKELEYDB_INCLUDE_DIRS})
  target_include_directories(database PUBLIC ${Boost_INCLUDE_DIRS} ${OPENSSL_INCLUDE_DIR} ${BERKELEYDB_INCLUDE_DIRS})

?

Sorry, the docs on it is just kind of confusing to me. Being my first CMakeLists doesn't help either

EDIT: Found this helpful post https://stackoverflow.com/questions/260 … s#26038443 and it does start building, but still fails on OpenSSL as always. Current code looks like..

  add_library(coin ${SOURCES})
  add_library(database ${DATABASE_SOURCES}) 

  target_include_directories(coin
    PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/coin/include
    PUBLIC  ${Boost_INCLUDE_DIRS}
    PUBLIC  ${OPENSSL_INCLUDE_DIR}
    INTERFACE  ${BERKELEYDB_INCLUDE_DIRS})

  target_include_directories(database
    PUBLIC ${CMAKE_CURRENT_SOURCE_DIR}/database/include
    PUBLIC  ${Boost_INCLUDE_DIRS}
    PUBLIC  ${OPENSSL_INCLUDE_DIR})

Last edited by sum01 (2017-07-14 07:31:41)

sum01 · 2017-07-15 07:05:53

I've tried setting the variables as cache and forcing them (inside of the custom OpenSSL module), which shows as the correct paths, but doesn't get used by the header file. Did that here https://github.com/sum01/vcash/blob/add … .cmake#L57

I've also tried just setting various -DOPENSSL flags to manually link to the root/include/libraries, but it didn't work as the regular FindOpenSSL module just overwrites them.

Last edited by sum01 (2017-07-15 18:11:24)

sum01 · 2017-07-18 15:46:17

Just a little update, I've found some build flags that almost make FindOpenSSL get the version I want, but it fails to get OPENSSL_CRYPTO_LIBRARY specifically.

-DOPENSSL_ROOT_DIR="/usr/include/openssl-1.0" -DOPENSSL_USE_STATIC_LIBS=TRUE -DCMAKE_FIND_LIBRARY_SUFFIXES=".so.1.0.0"

I've been trying to figure out where the problem is in the module that makes it unable to get the crypto lib, but all I can do is guess that it has something to do with..

  find_library(OPENSSL_CRYPTO_LIBRARY
    NAMES
      crypto
    NAMES_PER_DIR
    ${_OPENSSL_ROOT_HINTS_AND_PATHS}
    HINTS
      ${_OPENSSL_LIBDIR}
    PATH_SUFFIXES
      lib
  )

which is looking for crypto instead of libcrypto?

I've tried setting _OPENSSL_LIBDIR and _OPENSSL_ROOT_PATHS as those don't actually seem to get set anywhere, but with no effect.

Last edited by sum01 (2017-07-19 22:18:35)

The Infinity · 2017-08-05 14:54:25

Using FindOpenSSL is likely not going to work for openssl-1.0. If you use the official openssl-1.0 package, there are no static libs provided. So specifying `-DOPENSSL_USE_STATIC_LIBS=TRUE` would be wrong. Setting `-DOPENSSL_ROOT_DIR="/usr/include/openssl-1.0"` looks wrong as well. I suppose this variable must be set to the install prefix. Openssl 1.1 and 1.0 are installed in the same prefix (and just conflicting parts moved in subdirs) under Arch. So this variable is likely not helpful to distinguish between the versions.

Instead of trying to find non-standard OpenSSL via FindOpenSSL, try to make the OpenSSL library and header locations configurable by the user. Do do this explicitely, use `set(... CACHE ...)`. Of course a fallback to a default location would still be nice. I think FindOpenSSL already provides this approach which does not seem uncommon. At least also qca uses it (also to be able to use legacy OpenSSL): https://git.archlinux.org/svntogit/pack … es/qca#n43

BTW: That FindOpenSSL is looking for crypto rather than libcrypto should not be a problem. I suppose prefixes and suffixes can be omitted here.

EDIT: Oh, I see you have already fixed the problem. Your final solution looks like the same as in the mentioned qca PKGBUILD :-)

Last edited by The Infinity (2017-08-05 15:00:50)

Arch Linux

#1 2017-07-13 16:44:26

[Solved] C++ OpenSSL-1.0 compatibility

#2 2017-07-13 22:33:29

Re: [Solved] C++ OpenSSL-1.0 compatibility

#3 2017-07-14 06:08:46

Re: [Solved] C++ OpenSSL-1.0 compatibility

#4 2017-07-15 07:05:53

Re: [Solved] C++ OpenSSL-1.0 compatibility

#5 2017-07-18 15:46:17

Re: [Solved] C++ OpenSSL-1.0 compatibility

#6 2017-08-05 14:54:25

Re: [Solved] C++ OpenSSL-1.0 compatibility

Board footer