Hi,

I have a shared library that is linked to 'libcrypto.so.6' and 'libssl.so.6' but I don't have those versions in my system. The shared library is from a third party so I cannot compile it in my environment.

When I do 'ldd' I get the following:
linux-gate.so.1 => (0xb7f6c000)
libcrypto.so.6 => not found
libssl.so.6 => not found
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e40000)
libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb7e3c000)
libidn.so.11 => /usr/lib/libidn.so.11 (0xb7e09000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7d1a000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7cf4000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7ce5000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7b81000)
/lib/ld-linux.so.2 (0xb7f6d000)

What I need is to replace 'libcrypto.so.6' with 'libcrypto.so' so it uses the symbolic links from '/usr/lib/'

I know Mac has a tool called 'install_name_tool' that can change the dependencies manually of a dynamic library, but I couldn't find something similar for Linux.

Any help is much appreciated!

if the api hasn't change from libcrypto.so.6/libssl.so.6 to the one you have you can just symlink the name to yours and it should work

Thanks for your reply. Yes I am currently doing that but since I have to deploy the application for end users, I don't want to use symlinks to solve the problem.

you could always hex edit the binary and change the library name in the dynamic section (might be able to do it with objcopy)

As far as I know binaries are linked to the soname, which is hard-coded into the library. That means a symlink probably won't fool ld.so. The versionless symlinks are generally so that the linker selects the most-current version, at which time new binaries should be linked to the soname of the library pointed to by that link.
Kevin Barry

PS Generally the soname won't change unless the API changes; this dynamic loading problem is intentional in that sense.

ta0kira - symlinks work fine with ld.so in fact if you go and look you'll see lots of soname links, like libz.so.1 linked to libz.so.1.2.3.3 and such like that

That's because ldconfig creates symlinks matching sonames so that it points to the most-recent version. Chances are no normal system has a soname-named symlink pointing to a library with a different compiled-in soname. There's really no way to simulate such a situation (to see if it works) unless you're in the same situation as OP.
Kevin Barry

Here is a real example that I found in my /usr/lib

lrwxrwxrwx 1 root root 19 Nov 11 22:36 libcurl-gnutls.so.3 -> libcurl-gnutls.so.4
lrwxrwxrwx 1 root root 23 Nov 11 22:36 libcurl-gnutls.so.4 -> libcurl-gnutls.so.4.1.1
-rw-r--r-- 1 root root 270368 Nov 11 07:46 libcurl-gnutls.so.4.1.1

You misunderstand what I'm saying.

1. You probably don't have a library in /usr/lib with a soname of libcurl-gnutls.so.3 (if you did, ldconfig would have deleted the symlink you see and it would have created a new one pointing to such a library)
2. Because of that, you probably don't have any binaries or libraries with reference to a library with that soname
3. This symlink is probably to fool a build script into linking to libcurl-gnutls.so.4 when it tries to link to libcurl-gnutls.so.3
4. This should result in newly-linked binaries and libraries having reference to libcurl-gnutls.so.4, not to libcurl-gnutls.so.3

As I implied before, unless you can find a program or library listing libcurl-gnutls.so.3 in its ldd output, you probably don't have a comparable situation to OP.
Kevin Barry

Well maybe this will convince you, /bin/ls.

ldd /bin/ls
linux-vdso.so.1 => (0x00007fff115ff000)
librt.so.1 => /lib/librt.so.1 (0x00007fd90d96b000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00007fd90d74e000)
libacl.so.1 => /lib/libacl.so.1 (0x00007fd90d546000)
libc.so.6 => /lib/libc.so.6 (0x00007fd90d1f2000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fd90cfd6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd90dba1000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fd90cdd1000)
libattr.so.1 => /lib/libattr.so.1 (0x00007fd90cbcd000)


excerpt from objdump -p /bin/ls
Dynamic Section:
NEEDED librt.so.1
NEEDED libselinux.so.1
NEEDED libacl.so.1
NEEDED libc.so.6


that was just to establish that the soname of libc that it wants is libc.so.6

on my linux system /lib/libc.so.6 is a symlink, and its not pointing to anything that resembles libc.so.6, the dynamic linker doesn't care what the symlink points at as long as it satisfies the symbols its looking for

lrwxrwxrwx 1 root root 14 Nov 30 12:11 /lib/libc.so.6 -> libc-2.10.2.so

You still haven't shown that the soname for libc-2.10.2.so is something other than libc.so.6. The name of the library has nothing to do with the soname; the soname is specified as a linker option and it can be anything the developer wants it to be. If you can demonstrate that the soname for libc-2.10.2.so is something other than libc.so.6 then I'll be convinced. I'm not convinced you even know what a soname is.
Kevin Barry

I'm sorry you aren't convinced. soname in the libraries provides a hint and gives the dynamic linker a way to prefer one library over another but if the correct soname doesn't exist in the libraries it'll fallback to using the filename.

To test this I made a chroot area that has a modified libc-2.10.2.so, named libc-2.10.2_mod.so that has its soname set to libc.so.5, the chroot area also had the other libraries needed to run bash, ls, ldd, and cat

ls -R /tmp/chroot
/tmp/chroot:
bin lib lib64 usr

/tmp/chroot/bin:
bash cat ls

/tmp/chroot/lib:
libacl.so.1 libattr.so.1 libc-2.10.2_mod.so libc.so.6 libdl.so.2 libncurses.so.5 libpthread.so.0 librt.so.1 libselinux.so.1

/tmp/chroot/lib64:
ld-linux-x86-64.so.2

/tmp/chroot/usr:
bin

/tmp/chroot/usr/bin:
ldd


excerpt from objdump -p libc-2.10.2_mod.so

Dynamic Section:
NEEDED ld-linux-x86-64.so.2
SONAME libc.so.5

ldd /bin/ls
linux-vdso.so.1 => (0x00007fff425ca000)
librt.so.1 => /lib/librt.so.1 (0x00007fc052409000)
libselinux.so.1 => /lib/libselinux.so.1 (0x00007fc0521ec000)
libacl.so.1 => /lib/libacl.so.1 (0x00007fc051fe4000)
libc.so.6 => /lib/libc.so.6 (0x00007fc051c90000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc051a74000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc05263f000)
libdl.so.2 => /lib/libdl.so.2 (0x00007fc05186f000)
libattr.so.1 => /lib/libattr.so.1 (0x00007fc05166b000)

lrwxrwxrwx 1 root root 18 Dec 11 22:52 libc.so.6 -> libc-2.10.2_mod.so


chroot /tmp/chroot
bash-4.0# ls
bin lib lib64 usr

ls worked fine (actually bash did to for that matter) and without a matching soname

Very well.
Kevin Barry