Building from source root_v6.26.00 failing with openssl on MacOS Monterey

I downloaded root_v6.26.00.source.tar.gz and attempted to build it on my MacOS Monterey using cmake (cmake version 3.22.2) option:

cmake -DCMAKE_INSTALL_PREFIX=/Users/jade/thirdParty/root-6.26.00/build-artifact -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -Droot7=ON ..

but when attempting to build it, I get this compilation error:

/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/XrdCrypto/XrdCryptosslRSA.cc:504:19: error: no matching function for call to 'RSA_private_encrypt'
      if ((lout = RSA_private_encrypt(lc, (unsigned char *)&in[kk],
                  ^~~~~~~~~~~~~~~~~~~
/opt/local/include/openssl/rsa.h:285:5: note: candidate function not viable: 4th argument ('const struct rsa_st *') would lose const qualifier
int RSA_private_encrypt(int flen, const unsigned char *from, unsigned char *to,
    ^

During cmake configuration, it picked up openssl3:
– Found OpenSSL: /opt/local/libexec/openssl3/lib/libcrypto.dylib (found version “3.0.1”)

So I figured that root won’t build with a newer openssl but I can’t downgrade the default version of openssl since other tools are dependent on openssl3. I do still have older openssl (1.1.1m) still present on my system but on a different directory. So I attempted to set the cmake configuration to reference the older openssl (1.1.1m) version instead of the default openssl3:

cmake -DCMAKE_INSTALL_PREFIX=/Users/jade/thirdParty/root-6.26.00/build-artifact -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -Droot7=ON -DOPENSSL_INCLUDE_DIR=/opt/local/libexec/openssl11/include -DOPENSSL_CRYPTO_LIBRARY=/opt/local/libexec/openssl11/lib/libcrypto.dylib -DOPENSSL_SSL_LIBRARY=/opt/local/libexec/openssl11/lib/libssl.dylib ..

But despite using these cmake openssl options, the configuration log noted this:
– Found OpenSSL: /opt/local/libexec/openssl11/lib/libcrypto.dylib (found version “3.0.1”)
It is pointed to the correct and older version of openssl library but notes the wrong version.

So I then tried the other cmake option -DOPENSSL_ROOT_DIR:

cmake -DCMAKE_INSTALL_PREFIX=/Users/jade/thirdParty/root-6.26.00/build-artifact -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -Droot7=ON -DOPENSSL_ROOT_DIR=/opt/local/libexec/openssl11/ ..

With the above cmake option, during its configuration, it finally recognized the correct version of openssl:
– Found OpenSSL: /opt/local/libexec/openssl11/lib/libcrypto.dylib (found version “1.1.1m”)

But when I build it I get the same compilation error:

/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/XrdCrypto/XrdCryptosslRSA.cc:504:19: error: no matching function for call to 'RSA_private_encrypt'
      if ((lout = RSA_private_encrypt(lc, (unsigned char *)&in[kk],
                  ^~~~~~~~~~~~~~~~~~~
/opt/local/include/openssl/rsa.h:285:5: note: candidate function not viable: 4th argument ('const struct rsa_st *') would lose const qualifier
int RSA_private_encrypt(int flen, const unsigned char *from, unsigned char *to,
    ^

I don’t know why when it compiles XrdCryptosslRSA.cc it’s still referencing headers at /opt/local/include/openssl (which is pointed to openssl3):

jade$ ls -l /opt/local/include/openssl
lrwxr-xr-x  1 root  admin  43 Dec 20 00:57 /opt/local/include/openssl -> /opt/local/libexec/openssl3/include/openssl

as I noted earlier, I really don’t want to redirect where /opt/local/include/openssl points to, since other tools are dependent on it.

I specifically set the cmake configuration to reference openssl root at /opt/local/libexec/openssl11, which has the include & lib:

jade$ ls -l /opt/local/libexec/openssl11
total 0
drwxr-xr-x   4 root  admin  128 Mar  5 18:46 bin
drwxr-xr-x   3 root  admin   96 Mar  5 18:46 etc
drwxr-xr-x   3 root  admin   96 Mar  5 18:46 include
drwxr-xr-x  10 root  admin  320 Mar  5 18:46 lib
drwxr-xr-x   4 root  admin  128 Mar  5 18:46 share

I don’t know why during compilation it’s not picking up the specified header version of openssl during cmake’s configuration. What am I doing wrong here? How can I get root source to build against openssl 1.1.1m, while leaving the default openssl in my system pointed to openssl3 (since root fails to compile against openssl3)?

I’ve attached the configuration log from the last cmake options and its compilation error log
myconfig.txt (12.3 KB)
XROOTD-build-err.txt (62.8 KB)

Finally I notice that in the configuration log, it notes (despite finding pthread):
– Threads disabled.

How do I enable this? I tried to look in the root cmake options documented here, but the only options that refers to threading is imt which by default is on. But even when I added -Dimt=ON explicitly, doesn’t seem to make a different (Threads still disabled).

Did you try to search for similar issues on this forum? For example: Build error from XROOTD

@bellenot that’s not the same compilation error. The problem is, despite the specified openssl version being passed to root’s cmake options, it’s not getting passed to xrootd and so xrootd doesn’t compile against the specified (older version of) openssl, since xrootd doesn’t build against the newer openssl3.

Root’s cmake should be passing the cmake options passed to it to xrootd, when building xrootd.

Then maybe a MacOS expert (@couet or @Axel ) can help here

We have not enabled openssl3 for Xrootd; according to this we would need to adjust our cmake invocation for Xrootd. You are welcome to just try that and report whether it helps!

I agree with you that CMake seems to find an inconsistent combination of library and header. Looking at our invocation of ExternalProject_Add(XROOTD I see that we don’t pass any openssl location info to the sub-cmake. We should fix that; that’s now Difficult to configure Xrootd to use non-builtin openssl · Issue #10075 · root-project/root · GitHub

Until then you might be more lucky with exporting the CMAKE_PREFIX_PATH environment variable.

Alternatively you can build xrootd separately, with the correct ssl, and tell ROOT to build against that.

@Axel I did try passing -DWITH_OPENSSL3=TRUE to root’s cmake, and it does nothing (get same error). The referenced link you referred to is passing that option to xrootd. But if root build is not passing any cmake options to it when building xrootd, passing -DWITH_OPENSSL3=TRUE to root’s cmake isn’t going to do anything.

I’ll see if the CMAKE_PREFIX_PATH works. But if that doesn’t work and I have to manually build xrootd separately, what is root’s cmake options to let root know where the xrootd can be found (because I’m likely going to place its build artifacts in a nonconventional local area)?

BTW @Axel I tried exporting:

jade$ export CMAKE_PREFIX_PATH=/opt/local/libexec/openssl11
jade$ echo $CMAKE_PREFIX_PATH
/opt/local/libexec/openssl11
jade$ cmake -DCMAKE_INSTALL_PREFIX=/Users/jade/thirdParty/root-6.26.00/build-artifact -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -Droot7=ON ..

And root’s configuration does pickup the correct openssl version:
– Found OpenSSL: /opt/local/libexec/openssl11/lib/libcrypto.dylib (found version “1.1.1m”)

But when building root, it’s still failing with the same xrootd compilation error:

/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/XrdCrypto/XrdCryptosslRSA.cc:504:19: error: no matching function for call to 'RSA_private_encrypt'
      if ((lout = RSA_private_encrypt(lc, (unsigned char *)&in[kk],
                  ^~~~~~~~~~~~~~~~~~~
/opt/local/include/openssl/rsa.h:285:5: note: candidate function not viable: 4th argument ('const struct rsa_st *') would lose const qualifier
int RSA_private_encrypt(int flen, const unsigned char *from, unsigned char *to,
    ^

It’s still referencing the wrong openssl version. I don’t know if xrootd is using find_package to find where openssl is, because it should have picked up the CMAKE_PREFIX_PATH environment setting (root config certainly had no trouble picking it up).

So I guess now the only alternative is manually building xrootd. What are the cmake options to pass to root, to let it know where my xrootd build artifacts are?

Also what are root’s cmake options to have threads enabled (it seems to be turned off for my build, despite finding pthread).

You could actually edit builtins/xrootd/CMakeLists.txt from ROOT, and pass -DWITH_OPENSSL3=TRUE there.

Else yes, please build Xrootd separately. Again, CMAKE_PREFIX_PATH should help ROOT’s CMake build to find your Xrootd build.

The message on disabled threading support is from llvm; you can ignore it.

@Axel, so I edited builtins/xrootd/CMakeLists.txt as you suggested, added -DWITH_OPENSSL3=TRUE, so that it’s building against openssl3 but xrootd build fails, this time with a different error:

/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/XrdSec/openssl3/XrdSecProtect.cc:57:8: error: unknown type name 'EVP_MD_CTX'
static EVP_MD_CTX* EVP_MD_CTX_new() {
       ^
/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/XrdSec/openssl3/XrdSecProtect.cc:58:3: error: unknown type name 'EVP_MD_CTX'
  EVP_MD_CTX *ctx = (EVP_MD_CTX *)OPENSSL_malloc(sizeof(EVP_MD_CTX));
...

Despite xrootd offering that cmake option -DWITH_OPENSSL3=TRUE, it doesn’t look like it can build against openssl3.

So I went back to editing builtins/xrootd/CMakeLists.txt and see if I can get it working with older version of openssl (1.1.1m), by explicitly passing it the openssl cmake options.

So I noticed that before the ExternalProject_Add call, it does this

find_package(OpenSSL REQUIRED).  

I also notice that -DCMAKE_PREFIX_PATH:STRING=${OPENSSL_PREFIX} was passed to ExternalProject_Add, which turns out to be blank (I added a print statement that sampled OPENSSL_PREFIX just before ExternalProject_Add to verify this). I don’t think find_package(OpenSSL …) fills that variable. So that likely overrode my CMAKE_PREFIX_PATH environment setting to blank. But even if I explicitly set -DCMAKE_PREFIX_PATH:STRING=/opt/local/libexec/openssl11, still same compilation error.

So instead, I added the following options to ExternalProject_Add:

-DOPENSSL_INCLUDE_DIR=/opt/local/libexec/openssl11/include
-DOPENSSL_LIBRARIES=/opt/local/libexec/openssl11/lib/libssl.dylib;/opt/local/libexec/openssl11/lib/libcrypto.dylib

Still failed to compile (didn’t reference the correct header path). So tried this option:

-DOPENSSL_ROOT_DIR=/opt/local/libexec/openssl11

Still failed to compile (didn’t reference the correct header path). So tried this option:

-DOPENSSL_INCLUDE_DIR=/opt/local/libexec/openssl11/include 
-DOPENSSL_SSL_LIBRARY=/opt/local/libexec/openssl11/lib/libssl.dylib 
-DOPENSSL_CRYPTO_LIBRARY=/opt/local/libexec/openssl11/lib/libcrypto.dylib

and it still had the same compilation failure. For the last set of options, I looked at ExternalProject_Add config log and I see this printout:
– Found OpenSSL: /opt/local/libexec/openssl11/lib/libssl.dylib;/opt/local/libexec/openssl11/lib/libcrypto.dylib

I’ll upload that config log here:
XROOTD-configure-err.txt (3.1 KB)
XROOTD-configure-out.txt (5.1 KB)

And here’s the corresponding XROOTD-configure-Release.cmake (added the suffix .txt to it only because it wouldn’t let me upload it with a suffix .cmake):
XROOTD-configure-Release.cmake.txt (3.5 KB)

So it’s finding the correct openssl library versions, but it continues to reference the wrong openssl headers. Sadly there’s nothing in its configuration that logs the openssl header as it does with the libraries. I know it’s still referencing the wrong header because it notes it in the compilation error:

/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/XrdCrypto/XrdCryptosslRSA.cc:504:19: error: no matching function for call to 'RSA_private_encrypt'
      if ((lout = RSA_private_encrypt(lc, (unsigned char *)&in[kk],
                  ^~~~~~~~~~~~~~~~~~~
/opt/local/include/openssl/rsa.h:285:5: note: candidate function not viable: 4th argument ('const struct rsa_st *') would lose const qualifier
int RSA_private_encrypt(int flen, const unsigned char *from, unsigned char *to,
    ^

XROOTD build still references the wrong header path /opt/local/include/openssl/, despite being passed -DOPENSSL_INCLUDE_DIR=/opt/local/libexec/openssl11/include. Don’t know any other way around this.

@Axel I found another clue as to why it’s picking up the wrong openssl header. I cd’ed to the xrootd source code that root downloaded and explicitly issued the cmake command that ExternalProject_Add used and then ran the build with VERBOSE=1 just so I can see the include paths that was passed to the compiler and this is what I found:

[ 7%] Building CXX object src/CMakeFiles/XrdUtils.dir/XrdCrypto/XrdCryptoRSA.cc.o
cd /Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/mybuild/src && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DHAVE_ATOMICS -DHAVE_CRYPT -DHAVE_CURL_MULTI_WAIT -DHAVE_DH_PADDED_FUNC -DHAVE_FSTATAT -DHAVE_GETIFADDRS -DHAVE_LIBZ -DHAVE_NAMEINFO -DHAVE_READLINE -DHAVE_SSL -DHAVE_STRLCPY -DHAVE_XML2 -DHAVE_XRDCRYPTO -DLT_MODULE_EXT=".dylib" -DXRDPLUGIN_SOVERSION=“5” -DXrdUtils_EXPORTS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/opt/local/include -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/… -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/. -I/opt/local/include/ossp -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/mybuild/src -I/usr/local/include -I/opt/local/libexec/openssl11/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Kerberos.framework/Headers -std=c++17 -Wc++11-narrowing -Wsign-compare -Wsometimes-uninitialized -Wconditional-uninitialized -Wheader-guard -Warray-bounds -Wcomment -Wtautological-compare -Wstrncat-size -Wloop-analysis -Wbool-conversion -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -pthread -stdlib=libc++ -Wno-deprecated-declarations -O3 -DNDEBUG -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk -fPIC -std=gnu++14 -MD -MT src/CMakeFiles/XrdUtils.dir/XrdCrypto/XrdCryptoRSA.cc.o -MF CMakeFiles/XrdUtils.dir/XrdCrypto/XrdCryptoRSA.cc.o.d -o CMakeFiles/XrdUtils.dir/XrdCrypto/XrdCryptoRSA.cc.o -c /Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/XrdCrypto/XrdCryptoRSA.cc

So from the above compilation line, the ordering of the include path is this:

-I/opt/local/include -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/… -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src/. -I/opt/local/include/ossp -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/src -I/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/mybuild/src -I/usr/local/include -I/opt/local/libexec/openssl11/include -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX12.1.sdk/System/Library/Frameworks/Kerberos.framework/Headers

So the problem is, that -I/opt/local/include comes first before -I/opt/local/libexec/openssl11/include. The openssl3 headers are found under /opt/local/include, whereas openssl 1.1.1m is found under /opt/local/libexec/openssl11/include, which explains why the compilations is picking up the openssl3 headers instead of openssl1.1.1m headers.

One would have thought that cmake would have known that there was a specified openssl header location and would have placed /opt/local/libexec/openssl11/include before /opt/local/include when setting the include paths in the compilation.

I can understand why /opt/local/include was included since it probably had other library dependencies, whose headers are found in that directory. I don’t know how to get past this and I don’t know enough about cmake to get the include path ordered correctly, so that it would pick up the correct openssl headers.

OK what a mess. The easiest way out here is to build Xrootd separately and feed that to ROOT’s configuration.

@Axel, my last post was my attempt to manually build Xrootd. I just worked off from root’s download of Xrootd source code.

So even if I manually download Xrootd and attempt to build it, specifying the openssl version, I’m going to come across the same problem since it’s the same source code that root downloaded. Xrootd’s cmake setup is just not ordering the includes correctly.

Oddly enough, when I went digging in Xrootd’s source code, they had this cmake directory that seemed to have their own FindOpenSSL.cmake:

jade$ pwd
/Users/jade/thirdParty/root-6.26.00/build-dir/builtins/xrootd/XROOTD-prefix/src/XROOTD/cmake
jade$ ls
FindAutoConf.cmake      FindLibTool.cmake       FindReadline.cmake      FindVOMS.cmake          XRootDCommon.cmake      XRootDOSDefs.cmake
FindAutoMake.cmake      FindLibUuid.cmake       FindSciTokensCpp.cmake  FindYasm.cmake          XRootDConfig.cmake.in   XRootDSummary.cmake
FindCPPUnit.cmake       FindMacaroons.cmake     FindSystemd.cmake       Findfuse.cmake          XRootDDefaults.cmake    XRootDSystemCheck.cmake
FindKerberos5.cmake     FindOpenSSL.cmake       FindTinyXml.cmake       GNUInstallDirs.cmake    XRootDFindLibs.cmake    XRootDUtils.cmake

Is that normal? I don’t know why they had to create one when all they had to do was use cmake’s find_package to find the specified OpenSLL. I wonder if that’s what is causing problems of setting the include path correctly. It’s difficult for me to see how cmake is creating the ordering of the include path. It should have placed the specified OPENSSL_INCLUDE_DIR path first before any other include path, since it was explicitly specified.

I would appreciate if you could discuss this with the xrootd developers then, at Issues · xrootd/xrootd · GitHub - this is something they might be able to address. You can just link to your post here, to save some time. I hope you can do this - there’s a fair chance that others will run into this as well!

@Axel, created this post on the xrootd github.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.