Linking to SSL shared library of different versions

Question

My app uses only functions supported in OpenSSL 0.9.8 and later, but I compile it on a system with a 1.0.0 library installed (with -lcrypto), and the app requires libcrypto.so.1.0.0 or later at install time.

OpenSSL apparently compiles the entire version level "libcrypto.so.1.0.0" into the SONAME of the library, so my app won't run unless this specific version of the library exists. I get that it won't run on a system with only 0.9.8 installed, but what if 1.0.1 is installed?

For every other shared library I use (-lpthreads, -lncurses, ..), ldd shows the SONAME as "libxxx.so.N", so I only need version N installed. OpenSSL is the only library I'm aware of that depends on a very specific version level (V.R.M), so I worry that the app won't run if the installed library is later than libcrypto.so.1.0.0 (or the library is updated to a more recent level).

Is there a way to compile my app to use "libcrypto.so or "libcrypto.so.1" regardless of what version it's linked to? And why does OpenSSL use the full version in the SONAME when no other library I'm aware of does this?

Answer 1

No, there is no reliable way because in OpenSSL the internal structures keep changing between versions, and quite a few functions are actually macros which access/manipulate the structure members directly.

Still if you are SURE your application does not use any such macros and willing to take the risk the structures may change and your app won't work, you can dlopen() the libcrypto.so and dlsym() the functions you use. There would be around 20 of them. Keep in mind that many functions you may be using, such as SSL_CTX_set_options and SSL_want_read/SSL_want_write are actually macros which result in calling the same functions.

Another option would be to link statically with libcrypto.a and libssl.a. This would also make your app to run on systems which do not have OpenSSL installed at all (although those are few). Expect this to add 300-900kb to the size of your app though.