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

NiLuJe · 08-20-2012, 06:46 PM

@twobo/knc1: The K3 does use ld-linux.so.3 (while my x86 host uses ld-linux.so.2. ARM ABI specific thingy?).

@twobob: That doesn't change the fact that the binutils ld you built seems to want to rely on the ld helper from the glibc you built, not the one shipped with the K3. (EDIT: because your 'new' glibc is seen before the K3's with your custom LD_LIBRARY_PATH, which I guess is what the LD_PRELOAD hack was used to workaround, although I have *no* idea if it's safe, or even a good idea at all. Having to use LD_PRELOAD isn't usually a great thing to begin with, and preloading the glibc does seem a bit extreme to me ^^).

Use readelf -l to check what ld helper your binaries are looking for, which is probably /lib/ld-linux.so.3 right now.

Keep in mind that ld-linux is a part of glibc, and I've never tried what you're doing (ie. loading a newer glibc with an older loader), but it's probably not all that surprising that it's failing

. The 'best' way to handle this is probably to use the newer version of everything (glibc AND loader), or the older version of everything (which is what I'm usually doing).

As for how to achieve that (using the new loader), besides replacing the Kindle's loader in the rootfs (which is not necessarily safe, like knc1 said, check, check, and triple check, before you try it ^^), I have no idea. Messing with the INTERP header on your custom binaries?

EDIT²: A quick google search leads to this utility: http://nixos.org/patchelf.html
So I guess switching the interp header in an elf binary isn't so crazy after all

.
The info about the dynamic-loader LDFLAGS is good to know, if you want to go that way without having to patch every single binaries after building them

.

08-20-2012, 06:46 PM	#12
NiLuJe BLAM! Posts: 13,477 Karma: 26012494 Join Date: Jun 2010 Location: Paris, France Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E	@twobo/knc1: The K3 does use ld-linux.so.3 (while my x86 host uses ld-linux.so.2. ARM ABI specific thingy?). @twobob: That doesn't change the fact that the binutils ld you built seems to want to rely on the ld helper from the glibc you built, not the one shipped with the K3. (EDIT: because your 'new' glibc is seen before the K3's with your custom LD_LIBRARY_PATH, which I guess is what the LD_PRELOAD hack was used to workaround, although I have no idea if it's safe, or even a good idea at all. Having to use LD_PRELOAD isn't usually a great thing to begin with, and preloading the glibc does seem a bit extreme to me ^^). Use readelf -l to check what ld helper your binaries are looking for, which is probably /lib/ld-linux.so.3 right now. Keep in mind that ld-linux is a part of glibc, and I've never tried what you're doing (ie. loading a newer glibc with an older loader), but it's probably not all that surprising that it's failing . The 'best' way to handle this is probably to use the newer version of everything (glibc AND loader), or the older version of everything (which is what I'm usually doing). As for how to achieve that (using the new loader), besides replacing the Kindle's loader in the rootfs (which is not necessarily safe, like knc1 said, check, check, and triple check, before you try it ^^), I have no idea. Messing with the INTERP header on your custom binaries? EDIT²: A quick google search leads to this utility: http://nixos.org/patchelf.html So I guess switching the interp header in an elf binary isn't so crazy after all . The info about the dynamic-loader LDFLAGS is good to know, if you want to go that way without having to patch every single binaries after building them . Last edited by NiLuJe; 08-20-2012 at 07:14 PM.