mjhjmtu

We're using a library which needs to load libssl in a version 1.0.*. It doesn't work with libssl.so.1.1. We need it to work on any Linux system.

We try to load various versions and this usually works, but on system of one customer there's just the following:

/usr/lib64/libssl.so.1.1.0g
/usr/lib64/libssl.so.10
/usr/lib64/libssl.so.1.0.2m
/usr/lib64/libssl.so.1.1

We're trying to load libssl.so.1.0 and libssl.so.1.0.2, but it doesn't find libssl.so.1.0.2m because of the trailing "m".

I wonder what's the naming scheme of libssl, if any?

Do we really need to provide our own version or is there a better way?

Should we loop from libssl.so.1.0.2z down to libssl.so.1.0.2a? Should we scan the library path manually?

I'm not sure how you're opening libssl - I assume dlopen()?

Searching a hard-coded list of directory paths for a library sounds rather fragile - you'd be better off letting the dynamic linker do the work for you. Perhaps parsing the output of ldconfig -p is worth trying? On a Debian system, I see the following:

$ ldconfig -p|grep ssl
libssl.so.1.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
libssl.so.1.0.2 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2

On a RHEL 7.4 system:

$ ldconfig -p|grep ssl
libssl3.so (libc6,x86-64) => /lib64/libssl3.so
libssl.so.10 (libc6,x86-64) => /lib64/libssl.so.10

Note that on the Debian system the library is in /usr/lib/x86_64-linux-gnu, whereas on the RHEL system it's in /lib64 (also note the widely varying library names). Unless you use something like the output of ldconfig, you're going to have to search all of those distribution-specific paths yourself if you plan to "work on any Linux system". Admittedly, the directory paths are listed in /etc/ld.so.conf but I think using ldconfig is probably still easier.