Re: Hard coding paths to shared libraries

["Zack Weinberg" <zack at codesourcery dot 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