glibc and ld.so both contain ldd. The ldd in glibc doesn't
treat libc5-linked applications correctly, but the ld.so ldd
does. For example, on a (working) WP7 installation, glibc
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40006000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4
libm.so.5 => not found
libc.so.5 => not found
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40100000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6
libc.so.6 => /lib/libc.so.6 (0x4011e000)
/lib/ld-linux.so.1 => /lib/ld-linux.so.2
but ld.so ldd and strace both report that it is correctly
linking against the libc5 libraries. This poses a
significant problem in diagnosing problems with libc5
applications like WordPerfect, as the tool people depend on
to see what libraries are being used is wrong.
the backwards compatibility hacks to get libc5 binaries running are
the not the cleanest things in the world, but they work.
Our glibc expert (Cristian Gafton) believes that the ldd that we are
shipping is much more reliable and advanced than the ldd you are
referring to in ld.so, which is why we use it.