MobileRead Forums - View Single Post - Benchmark. Benchmarking Ciphers. (And a handy test of the scripty wangle WIP)

NiLuJe · 08-20-2012, 08:04 PM

@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).

08-20-2012, 08:04 PM	#24
NiLuJe BLAM! Posts: 13,507 Karma: 26047224 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@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.