uClibc, libstdc++, and readdir()

[Jeff Warren]

Okay,
	I got the readdir() to use get sys_getdents64 syscall. It seems that I
have to remove certain .o (readdir.o) files or the makefile I am using
doesn't put the changes in the compiled library. I was deleting the
getdents.o and the getdents64.o but that didn't seem to do it.
>         I then look at my process and see with the gdb command 'info
> sharedlibrary' that libc.so.0 is not even loaded.  
Specifically, if I run ldd for the same app built on my x86 dev box I
see:
ldd /home/jwarren/Projects/flyerupdate/debug-x86/src/flyerupdate
       libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40029000)
        libm.so.6 => /lib/tls/libm.so.6 (0x400dc000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400fe000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

If ran on my arm target (AT91RM9200DK) using the ucLibc ldd app I see:
ldd /home/flyerupdate
        libstdc++.so.5 => /lib/libstdc++.so.5 (0x4000d000)
        libfloat.so.1 => /lib/libfloat.so.1 (0x4009a000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x400b9000)
        ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x40000000)

I understand on my x86 box it is using glibc, but the arm shouldn't it
have a dependency on libuClibc-0.9.26 or libc.so ? Is ld-uClibc.so
dynamically accessing the library for the application?

Regards,

Jeff Warren