ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
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)
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.
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
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.
PS Generally the soname won't change unless the API changes; this dynamic loading problem is intentional in that sense.
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.
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)
Because of that, you probably don't have any binaries or libraries with reference to a library with that soname
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
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.
Last edited by ta0kira; 12-11-2009 at 03:49 PM.
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
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.
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