Hi,

I've been testing some builds of XRootD against different builds of openssl on a CentOS7 host.
The version of openssl shipping with CentOS7 is causing us real problems and is triggering segfaults under production workloads.

TL;DR

My custom compiled version of XRootD looks for the wrong library files at runtime, i.e. libssl.so.1.0.0 rather than libssl.so.1.1 or libssl.so

Building XRootD

I've tested with OpenSSL-1.1.1n and OpenSSL-3.0.2 and unfortunately see the same problem.

For building on a CentOS7 host I find I have to also update the voms c++ headers to avoid extra problems at build time so I'm building against voms 2.1rc2 and different openssl versions manually compiled and installed under /opt.

I'm building from master with the following cmake options, in this case for openssl-1.1.1n, using gcc11 from the devtoolset:

git pull https://....
cd xrootd; mkdir build; cd build;
cmake3 -DCMAKE_BUILD_TYPE=RelWithDebInfo -DBUILD_TESTS=True -DCMAKE_CXX_FLAGS="-lcppunit -Wl,-Bdynamic" -DXRD_PYTHON_REQ_VERSION=3.6 -DOPENSSL_ROOT_DIR=/opt/openssl-1.1.1n -DOPENSSL_INCLUDE_DIR=/opt/openssl-1.1.1n/include -DOPENSSL_SSL_LIBRARY=/opt/openssl-1.1.1n/lib/libssl.so -DOPENSSL_CRYPTO_LIBRARY=/opt/openssl-1.1.1n/lib/libcrypto.so -DCMAKE_INSTALL_PREFIX=/opt/xrootd-openssl111n -DVOMS_INCLUDE_DIR=/opt/voms/include -DVOMS_LIBRARIES=/opt/voms -DVOMS_LIBRARY=/opt/voms/lib64/libvomsapi.so ..
make -j; make install

(The DCMAKE_CXX_FLAGS flags represent the minimal change needed to get the tests to compile correctly on my machine)
The build completes fine but I hit a problem at runtime.

Runtime problem

When I attempt to run any of the binaries, they all quit with an error.

# /opt/xrootd-openssl111n/bin/xrdcp -V
/opt/xrootd-openssl111n/bin/xrdcp: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

The error is that they are looking for libcrypto.1.0.0 and libssl.1.0.0 regardless of which version of openssl I compile against.
(I am executing in an environment with LD_LIBRARY_PATH set to pick up the 'correct' openssl version from opt as part of my testing)

Workaround

The simple 'work-around' for this has been to make a ".so.1.0.0" symlink to the libcrypto and libssl libraries for OpenSSL-1.1.1n and OpenSSL-3.0.2 and which seems to work with ldd suggesting it's resolving the symbols from the correct library. but I don't know if I might be compiling this wrong on my system given the nature of the error.

# ln -sf libcrypto.so libcrypto.so.1.0.0
# ln -sf libssl.so libssl.so.1.0.0
# /opt/xrootd-openssl111n/bin/xrdcp -V
v5.4.2

# ldd /opt/xrootd-openssl111n/bin/xrdcp | grep libssl
	libssl.so.1.0.0 => /opt/openssl-1.1.1n/lib/libssl.so.1.0.0 (0x00007f2c7d52d000)

I don't know if this is a case of using the wrong cmake arg or something more complex, but this might impact others who find they can't upgrade from CentOS7 due to other issues such as hardware-compatibility.

Thanks for any help,

Rob

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/issues/1676@github.com>

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1