I have build my C++ application by dynamically linking the openssl library on SLES15 machine with openssl version OpenSSL 1.1.1d and running the application on SLES15SP1 with openssl version OpenSSL 1.1.0i-fips but the application is failing to run and exiting with below error "/usr/lib64/libssl.so.1.1: version `OPENSSL_1_1_1' not found"
My test machine is SLES15SP1 which has openssl version OpenSSL 1.1.0i-fips
V2A-GQL-S15SP1:/tmp/remoteinstall/WMISSH/3 # openssl version OpenSSL 1.1.0i-fips 14 Aug 2018
Where as my SLES15 build machine has higher openssl version OpenSSL 1.1.1d 163e172dceca:/ # openssl version OpenSSL 1.1.1d 10 Sep 2019
Is there such any requirement that the test machine need to have same or higher version of openssl than the build machine?
Please guide on how to build the C++ application with dynamic open ssl linkage so that the application can pick whatever version openssl present in system.
Please guide on how to build the C++ application with dynamic open ssl linkage so that the application can pick whatever version openssl present in system.
That is all but impossible. OpenSSL strongly versions their libraries because there are incompatible differences in the API between versions.
You would have to install a version of OpenSSL 1.1.0 that is compatible with the desired version on a development system, and then modify your application to work with that version. And once you have made the necessary changes, you would then have to test your application. Then deliver that version to the outdated systems.
In other words, you'd have to fork your application and maintain two branches. Do you have the resources to do that? For outdated systems that are past EOL?
Because those systems are out-of-date and past EOL. They will not be getting security updates. Per Overview of OpenSSL versions in SUSE Linux Enterprise Server, the only versions of SLES 15 with OpenSSL 1.1.0 were EOL'd over two years ago. And in about a month the only SLES 15 version that won't be EOL is SLES 15 sp5
And importantly, OpenSSL 1.1.1 itself EOL'd: "OpenSSL 1.1.1 was released on 11th September 2018, and so it will be considered EOL on 11th September 2023. It will no longer be receiving publicly available security fixes after that date."
SUSE likely has support in place to provide security-related fixes to their OpenSSL 1.1.1 packages, but that time is probably going to be limited. SUSE will probably change the version of OpenSSL in SLES 15 sp6 or sp7 to OpenSSL 3.0 because they won't have the resources to provide critical security fixes to OpenSSL 1.1.1 in the near future. RHEL 8, for example, shows no extended support past the middle of 2025 - only 18 months or so away. The EOL of OpenSSL 1.1.1 was a large driver in that decision.