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 ldd reports libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40006000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4004e000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x400f3000) 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 (0x40109000) libc.so.6 => /lib/libc.so.6 (0x4011e000) /lib/ld-linux.so.1 => /lib/ld-linux.so.2 (0x00000000) 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.