Benchmark. Benchmarking Ciphers. (And a handy test of the scripty wangle WIP)

[NiLuJe]

@knc1: Yeah, it should work *way* better when using a matching loader & glibc .

[twobob]

version is the latest 3.3 - OTA is the latest for sure. I noticed the last one bump me up.
No hassles.

Okay so it's a bad idea. I will look for a less extreme solution.
perhaps when I have more knowledge of the side effects I can make a better judgement of the implications.

I have a CORRECT headers build going thru right now. It is clear that I do *NOT* have the headers either a) at all and b) in the right place previously. RTFM. err Find TFM.

It amazes me how disparate the sources of information are. atomic and irrevocably separate shifting sands of information.

(well for the newer stuff anyways) and "Yes," I know anyways isn't a real word. meh.

Which only makes me all the happier to latch into something like BR.
with my ever increasing knowledge of latching in applications it should prove possible to even bundle in every kindle patch ever (some sort of external updating process would be nice, perhaps latch an RSS/XML/ATOM/W/E feed)

an example will be applying the nasty GOTCHA kernel header gotchas to the calling toolchain dynamically. (hmm I better install every TC ever - ho hum)

or perhaps -Optionally- pushing down the initial Yianfu bin to the resulting home Dir. That kind of thing.

Appreciate your efforts to make this work and so am doing the best possible to cram my side and provide quality information or resources to play with. Hopefully my shameful lack of knowledge and fearless online display of said dirty-underwear will one day prevent some other poor soul having to wash his digital trousers on here.

Wow that possibly the most protracted metaphor since John Feyns rant about software
I need some tea

Builds running nicely.

If we get this lot running "AS EXPECTED" - now I have the exact toolchain, right headers, I will then incrementally step up the TC set until I find the relevant versions of each TC that allows the - insert name here - app to build and document that for A) our viewing pleasure, B) so people know if it can be built - Native - or not.

And then finally develop the correct procedures - and documention - to get these (probably growing over time in number) corner case applications to run.

Forsee a day when the old TC just wont cut it anymore and perhaps a list of "Last ever version that can run on a kindle" may also be in order. But that sounds like a long job. One day perhaps.

Anyways, these are my thoughts. Throw rocks while I make tea.

[twobob]

Originally Posted by knc1

Yeah, I just checked the one image I have (3.2.1) and ld-linux.so.3 is a symlink to ld-2.5.so
The file dates are 4/6/2011

- - - -

Whatever, trying both loaders with an explicit call and a fixed list of libraries to load as I suggested in my above post will tell us more.

Yep. will do this. Thought it might be worth using the resulting - correct header - binaries for the job - hence the holdup. : )

I'll have a fiddle now.
err after a tea

[NiLuJe]

@twobob: Note that the ld-linux issue probably has *zero* relation the the kernel headers you used in your TC. It's related to the *glibc* version you built your stuff against (and more specifically, to the glibc version you're *loading* with a loader from an *older* glibc).

(In case I wasn't clear earlier, ld-linux.so.3 is a symlink to ld-N.N[.N].so, where N.N[.N] is the glibc version, and isn't the same thing as ld, the binary. ld-linux is the loader, it's a part of the glibc. ld the binary is the linker, it's a part of binutils).

[twobob]

sftp://root@k/mnt/us/lib: ls ld-*

ld-2.3.6.so
ld-linux.so.3

Version 3.3 (just checked)

[NiLuJe]

@twobob: Oookay, so you're actullay using an *older* glibc than the Kindle.

I didn't think that was possible . The K3's using glibc 2.5, which is already freaking ancient. glibc 2.3.6 is just straight up prehistoric ^^. (And don't remind me that I actually have used system running it, and older, please ).

Anyyyway, all the stuff about using matching loader/glibc still applies, but you can also try to use/build against the same glibc version as the Kindle, which should be 2.5 or 2.5.something (check the Amazon source releases).

EDIT: I'm not going through all my previous messages to switch older/newer where appropriate, but the meaning behind them still more or less applies.

[twobob]

Originally Posted by NiLuJe

@twobob: Note that the ld-linux issue probably has *zero* relation the the kernel headers you used in your TC. It's related to the *glibc* version you built your stuff against (and more specifically, to the glibc version you're *loading* with a loader from an *older* glibc).

(In case I wasn't clear earlier, ld-linux.so.3 is a symlink to ld-N.NN.so, where N.NN is the glibc version, and isn't the same thing as ld, the binary. ld-linux is the loader, it's a part of the glibc. ld the binary is the linker, it's a part of binutils).

err yeah. I was only demonstrating a failing binary. ld was just the example of something failing. sorry if that wasn't clear. bad example. It just had a nice obvious and predicatable fail sequence. Doh. apologies.

That said, I didn't actually know that exact roles as you just described, but as ld-linux is actually ON the system and ld is something the 'install' brought to the party I figured as much. Coupled with a lack of 'ld' on the system I figured it must be an autotools thingy and not to do with the loading. So err yeah I knew that. Kinda. In my own mangled way.

ld-2.3.6.so and ld-linux.so.3 are the ones in /mnt/us/lib

ld-2.5.so and ld-linux.so.3 are the ones in /lib : (

sigh. Just when I thought I had that issue put to bed : )

Do I really have to downgrade my OS version one step.
I have heard horror stories about rolling back version of gcc (okay it was on gentoo where that stuff really matters) so err... err.. yeah. any thoughts?
Hokay, I'll go check out how to install that? Curse my feeble mind.


okay well Ill try knc's way but it would be nice to make EXACTLY the right things if I am to make this stuff available for reference. Ta all.

The tea was lovely btw.

[twobob]

Originally Posted by NiLuJe

@twobob: Oookay, so you're actullay using an *older* glibc than the Kindle.

I didn't think that was possible . The K3's using glibc 2.5, which is already freaking ancient. glibc 2.3.6 is just straight up prehistoric ^^. (And don't remind me that I actually have used system running it, and older, please ).

Anyyyway, all the stuff about using matching loader/glibc still applies, but you can also try to use/build against the same glibc version as the Kindle, which should be 2.5 or 2.5.something (check the Amazon source releases).

EDIT: I'm not going through all my previous messages to switch older/newer where appropriate, but the meaning behind them still more or less applies.

err Okay.

I did had previously extracted the gllic from the kindle sources, but done nothing with them. Ill go read yet another FM. : )

Still I actually like that I am running an older one. : ) comforting somehow.

LET ME QUALIFY THAT: Perhaps with the updated Glibc I can convince a few more BR packages thru the hoops. We already managed a huge pile with the freaking ancient libs!!! glad to find we have a *little* bit more 'historic' overhead than originally thought.

kk. more manuals. got it.

Honestly, I had done little else but read since I got my kindle
HAHAHAHA I made a funny.

Jeepers must be getting tired. Right time to try the new kncWangle™ with Fries. TBC

[NiLuJe]

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

[twobob]

Ah thanks mate. I think the "correct" solution here is use the right version.

And never let it be said that I do the easy option. If I am honest my interest is in dragging some of the more 'interactive' features of these older kindles into the 21'st century. I WAS hoping for a QT5 build out of BR (and had managed this with the 2012 TC) so let's see what the new build brings.

It will be fun seeing if the new c version brings something to party. To be absolutely clear are there any specific GOTCHAS for having multiple installs of glibc on a system. Dont worry - Ill google it but you know if their is like a DUMBWITS GUIDE I'm all eyeballs.

I'm reading the FAQ's perhaps it is covered there.

Thanks you folks.


Configuring and compiling GNU Libc
==================================

GNU libc cannot be compiled in the source directory. You must build it
in a separate build directory. For example, if you have unpacked the
glibc sources in `/src/gnu/glibc-2.4', create a directory
`/src/gnu/glibc-build' to put the object files in. This allows

Just to prove I do actually read the README's. In case you were wondering...

Finally, configure glibc with the option
`--with-headers=/usr/src/linux-2.2.1/include'. Use the most recent
kernel you can get your hands on.

And that would be the amazon headers right? the i386 versions or?

[NiLuJe]

@twobob: If you keep them completely separate, and don't try to mix and match in the same process, like you were doing, it's safe. It's actually what's a multilib system is doing .

It's not necessarily always easy to manage, which is why we've nearly all been staying away from multilib systems/TC . Granted, the only experience I have with this is a bit rusty, with Gentoo's native x86_64/x86 multilib profiles.

[twobob]

this sounds a lot like switching from 5 to 6 then. have one handy, don't mash the others lots of prefix nonsense and hair-raising moments of OMG "I didn't just overwrite my system c libs as root did I?"

Great.

Ah well. I'll give it a go. and document the horror story if I survive.

Err. so the headers the i386 ones right? it's for my system so yeah? right? or its for the TC so arm... bah... resumes reading : (

EDIT: Multilib systems I hate you. Just saying.


I'm just thinking out loud here:

EDIT: Err no. Surely this is just for the TC.
you@dev ~/BLDS/buildroot $ gcc --version

gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

My local version is way newer than that so this must just be a TC specific thingy.

Goes to investigate.

[NiLuJe]

@twobob: I'm not sure what you meant :?

Your host (your system's native TC) is using, well, native stuff, probably x86 or x86_64, depending on your setup. You X-TC should be using stuff targeted at the target's arch, arm, in our cases.

To get back on the multiple glibc thing, if you keep it away from search paths, it's completely harmless.

For example, I have a crapload of different TCs in a folder in my $HOME. Each TC is in a separate subfolder there, and my searchpaths always contains only *one* of these x-tc when I'm x-building stuff. When I'm not, I don't tweak my searchpaths .

[twobob]

Originally Posted by NiLuJe

@twobob: I'm not sure what you meant :?

Your host (your system's native TC) is using, well, native stuff, probably x86 or x86_64, depending on your setup. You X-TC should be using stuff targeted at the target's arch, arm, in our cases.

To get back on the multiple glibc thing, if you keep it away from search paths, it's completely harmless.

For example, I have a crapload of different TCs in a folder in my $HOME. Each TC is in a separate subfolder there, and my searchpaths always contains only *one* of these x-tc when I'm x-building stuff. When I'm not, I don't tweak my searchpaths .

I just came to the same logical conclusion. Albeit it probably took me a fair while longer for it to dawn. so I build the c thingy. can do. then I guess I just have to get the TC to reference in some way. Sigh I wish I knew more. Oh well, keep learning.

Oh the build has finished brb,

[NiLuJe]

@twobob: The easier way to do that is probably to tell whatever you're using to build your toolchain (buildroot? ct-ng?) to use *this* specific glibc version when building your x-tc. (That does imply rebuilding *everything*, the toolchain, and each of every other stuff you might have built ifor your staged sysroot).