ldd is not honoring LD_LIBRARY_PATH

[u-uclibc-y2lt at aetey.se]

On Mon, Oct 10, 2011 at 10:49:01AM +0200, Carmelo AMOROSO wrote:
> We now fortunately have the opportunity to run uClibc ld.so in
> stand-alone mode as well, so this revised implementation should be safe.

Personally I do not see a big win in letting ldd apply a non-standard
search path.

This can be convenient but (IMHO) seldom important and (again IMHO)
never crucial.

The actual location of the libraries is easy to find out, given their
names and the [LD_LIBRARY_] path, without adding code and extra security
issues to think about to ldd.

Different people may have different preferences about the balance
of convenience and complexity, so the extra code and effort might
be worth the gain. Anyway, no gain for my actual use of ldd.

On the more philosophical level, I see ldd as a tool to explore
a binary, period. LD_LIBRARY_PATH does not belong to the binary
and the extra information "where the libraries would be found
given a certain search path" is useful but is not the binary's
property.

In my eyes the functionality would be more consequently implemented as
a script taking a list of libraries' names from ldd + a search path and
resolve the libraries to files.

If you think that such "purity" contradicts practical uses, it is quite
the opposite - I have to routinely parse glibc ldd output to get the
actual libraries' names instead of the "resolved" file names which is
_not_ what I need.

So, actually, I'd prefer "no resolution at all".
(Of course ldd should tell if the binary insists on looking in certain
places via RPATH - which I do not like but want to know.)

Regards,
Rune