Re: Hard coding paths to shared libraries

["Zack Weinberg" <zack at codesourcery dot com>]

Rocha Iran-QIR001 <Iran.Rocha@motorola.com> writes:

> 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.

The black magic I mentioned is not the same thing as the stuff
Alexandre was talking about.  DT_AUXILIARY is only black magic because
the way to create such entries is undocumented as far as I know (which
also means I don't know how to do it).

...
> 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.

This sounds like a more conventional problem involving bad RPATH
entries.  Suggest you run objdump --private-headers on the binary;
this will reveal whether it has a NEEDED entry for /vol/cp/.../foo.so,
an RPATH entry for /vol/cp/.../ and a NEEDED for foo.so, or something
else entirely.

Note that having the path /lib/ld-linux-ia64.so.2 hardcoded into the
binary is normal.  This is the dynamic linker, which has to be
referenced by absolute path, because the kernel has no other way of
finding it.

zw