This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Hard coding paths to shared libraries
- From: "Zack Weinberg" <zack at codesourcery dot com>
- To: Rocha Iran-QIR001 <Iran dot Rocha at motorola dot com>
- Cc: "'binutils at sources dot redhat dot com'" <binutils at sources dot redhat dot com>
- Date: Thu, 21 Aug 2003 12:20:06 -0700
- Subject: Re: Hard coding paths to shared libraries
- References: <4D87884B6A6D4E438A8592BCC9C85DCA0634F087@il02exm06.corp.mot.com>
Rocha Iran-QIR001 <Iran.Rocha@motorola.com> writes:
> I know that hard coding the path to a shared library is probably not a good
> idea. Nevertheless, I would like to know how to do it.
You probably want -rpath.
> I see the following in my Solaris machine:
>
>> /bin/ldd /bin/ls
> libc.so.1 => /usr/lib/libc.so.1
> libdl.so.1 => /usr/lib/libdl.so.1
> /usr/platform/SUNW,Ultra-60/lib/libc_psr.so.1
>
> Apparently, the path to libc_psr.so.1 was hard coded into the binary. How
> can I do the same if I want to?
You're mistaken; the path to libc_psr.so.1 is not hardcoded into
/bin/ls on solaris systems. ldd shows you the full paths to the
libraries that the dynamic linker chose, that's all. Observe:
$ uname -a
SunOS parsley 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-5_10
$ ldd /bin/ls
libc.so.1 => /usr/lib/libc.so.1
libdl.so.1 => /usr/lib/libdl.so.1
/usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
$ strings -a /bin/ls | grep lib
/usr/lib/ld.so.1
_lib_version
libc.so.1
libc.so.1
The binary doesn't mention libc_psr.so.1 at all! It's brought in
because of an AUXILIARY entry in libc.so.1 (which is created by black
magic, beyond the scope of this message).
zw