@twobob: the core issue is that you're using the Kindle's loader (ld-2.5.so) to load your custom libc, and that the two don't match. One is from glibc 2.5, while the other is from glibc 2.3.6. That's a bad idea.
You've got a couple of choices:
* Make sure the loader & glibc used always match. The elf tweaking stuff I mentionned/LDFLAGS setup would apply here. (either make sure everything you built is using the glibc/loader you built, or make sure everything is using the Kindle's loader/glibc. The second proposition is actually similar to my third point in your specific case, because you were building against an *older* glibc). If you go with the 'using your custom loader' way, that's not necessarily a safe bet, we can't be sure your older loader won't ever be asked to load a library from the Kindle's rootfs, and might barf on it.
* Make sure you're using the same glibc version as your target OS in your TC (rebuild everything against glibc 2.5, and use it. Ship it or don't, it shouldn't make a difference). (I just checked Amazon's source packages, they seem to be using more or less a plain old glibc 2.5 on the K3). That's what I'm doing for the K4/K5 stuff I release (without shipping glibc).
* Hope the ABI backward compatibility of glibc's versioning holds up, and *don't* ship your custom libc. Since you built against an *older* glibc, you shouldn't have much trouble. (Kill all the traces from your custom glibc from your staged root in /mnt/us, and try running your stuff as usual (with only the PATH/LD_LIBRARY_PATH tweak). It should hopefully work). That's what I'm currently doing for the K2/K3 stuff I release, albeit in the reverse way (I build against a *newer* glibc, while making sure nothing from said newer glibc is actually requested at compile-time).
Last edited by NiLuJe; 08-20-2012 at 08:21 PM.