2

I want to have openssl-1.0.2 and openssl-1.1.0 both available for dynamic linking to different applications. I'm slightly unsure about this, because I would expect 1.0.2 to be installed in a file called libssl.so.1.0.2 but it's actually in a file called libssl.so.1.0.0.

This the setup with only 1.0.2 installed:

/versions64/local/lib/libssl.so -> libssl.so.1.0.0
/versions64/local/lib/libssl.so.1.0.0

And this is what it looks like after 1.1.0 is installed:

/versions64/local/lib/libssl.so -> libssl.so.1.1
/versions64/local/lib/libssl.so.1.0.0
/versions64/local/lib/libssl.so.1.1

Are applications that require 1.0.2 going to know to look in libssl.so.1.0.0 and ignore libssl.so?

  • Have a look at how Debian is doing that; I have (or had, not sure after the updates), several servers with at least 2 versions of libssl – Rui F Ribeiro Jun 29 '17 at 10:43
0

I just tested it. I ran Apache 2.4, which was compiled to use OpenSSL 1.0.2. Apache started successfully and served an SSL site.

First I renamed the new libssl.so.1.1 library and Apache still restarted successfully. Then I renamed the new libssl.so link and Apache still started successfully. Finally I renamed the old libssl.so.1.0.0 library and Apache FAILED to restart.

This proves it is ignoring the libssl.so symlink and correctly using the libssl.so.1.0.0 that is was compiled against, as expected.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.