Relinking a shared library
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)
|
Quote:
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 |
Quote:
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 |
All times are GMT -5. The time now is 03:22 PM. |