Forcing a binary to use a specific (newer) version of a shared library (.so)

Question

I have an older binary executable (utserver, closed source) that I'm trying to run on a system running Fedora 22.

utserver wants openssl_1.0.0 - F22 provides openssl_1.0.1k

I made two symlinks:

$ sudo ln -s /usr/lib64/libssl.so.1.0.1k /usr/lib64/libssl.so.1.0.0
$ sudo ln -s /usr/lib64/libcrypto.so.1.0.1k /usr/lib64/libcrypto.so.1.0.0

But trying to run utserver complains about library version:

$ ./utserver
./utserver: /lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./utserver)
./utserver: /lib64/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./utserver)

OK, so it's looking for a version string. I edited the utserver ELF to change the string OPENSSL_1.0.0 to OPENSSL_1.0.1 but I get the same error (`OPENSSL_1.0.1' not found)

objdump and readelf both show OPENSSL_1.0.1 present in version area of libssl.so.1.0.1:

$ objdump -p /lib64/libssl.so.1.0.1 | grep OPENSSL
3 0x00 0x066a2b21 OPENSSL_1.0.1
4 0x00 0x02b21533 OPENSSL_1.0.1_EC
0x02b21533 0x00 07 OPENSSL_1.0.1_EC

so now I'm confused as to what utserver is actually checking for. I suspect it's seeing OPENSSL_1.0.1_EC and failing. If I add the _EC in the ELF I get a seg fault, presumably because now my offsets are all wrong.

$ readelf -d ./utserver 
readelf: Error: Unable to seek to 0x15da90000000 for string table
readelf: Error: no .dynamic section in the dynamic segment

Dynamic section at offset 0x154fb8 contains 34 entries:

Is there any way to tell ld-linux to force load OPENSSL_1.0.1_EC and/or a reference to modifying ELF offsets? Would be much appreciated.

Yes, I know I can find a version of openssl_1.0.0 packaged somewhere, but that's one library I'd rather not revert if I don't have to.

Answer 1

Is there any way to tell ld-linux to force load OPENSSL_1.0.1_EC

No.

There is a reason why the symbol versions have been changed: the old and new symbols are not ABI-compatible. You must recompile the executable to use the new symbols, or (easier) you must provide libssl.so.1.0.0 (which can be installed and co-exist with already installed libssl.so.1.0.1k).

that's one library I'd rather not revert if I don't have to.

You don't have to revert anything (and reverting will break all the programs that want the new version).

Simply providing the libssl.so.1.0.0 from an old package will make old programs (that require it) use that file, while new programs (which require libssl.so.1.0.1k) will continue to use libssl.so.1.0.1k.