This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Hard coding paths to shared libraries


Hi Alexandre, Zack, and Daniel,

Thank you very much for your prompt response. The '-rpath' would be the way to go but I am interested on the "black magic" that Zack mentioned below as Alexandre had surmised. This is the reason why I am looking for this info:

We have built a cross-compiler using GNU Binutils 2.13 and GCC 3.2.2. The host platform is sparc-sun-solaris2.6 and the target platform is ia64-linux. We are putting together software developed by many groups and shipping it for testing. When the testers run ldd on one of our binaries, they see this:

> ldd ohmt
        libpthread.so.0 => /lib/libpthread.so.0 (0x2000000000004000)
        librt.so.1 => /lib/librt.so.1 (0x20000000000b4000)
        libevl.so.1 => /usr/lib/libevl.so.1 (0x20000000000d8000)
        /vol/cp/bld/lib/log/linux_obj/liblog.so => not found
        /vol/cp/bld/lib/cevm/linux_obj/libcevm.so => not found
        /vol/cp/bld/lib/io_mgmt/linux_obj/libio_mgmt.so => not found
        /vol/cp/vendor/linux/hap_ckpt/pal-standalone.so => not found
        /vol/cp/vendor/linux/hap_ckpt/ckpt-lib.so => not found
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x200000000016c000)
        libm.so.6.1 => /lib/libm.so.6.1 (0x20000000002c4000)
        libc.so.6.1 => /lib/libc.so.6.1 (0x2000000000354000)
        /lib/ld-linux-ia64.so.2 => /lib/ld-linux-ia64.so.2 (0x2000000800000000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x20000000005b0000)

I am trying to dig into the code to understand what went wrong. It looks like the /vol/cp entries got hardcoded into our binary since the path is showing on the left side of the arrow ( => ). The same appears to have happened with the /lib/ld-linux-ia64.so.2. If I understand how can someone do this on purpose, it may help me spot the issue on the code that we have received from the developers. Any ideas? Sorry, if my original question was not straight to the point.

Thanks for the help,
Iran Rocha



-----Original Message-----
From: Zack Weinberg [mailto:zack@codesourcery.com]
Sent: Thursday, August 21, 2003 2:20 PM
To: Rocha Iran-QIR001
Cc: binutils@sources.redhat.com
Subject: Re: Hard coding paths to shared libraries


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]