Tools Snapshots of NiLuJe's hacks

[knc1]

Originally Posted by knc1

but this one is really strange:

[root@kindle root]# eu-objdump -d /bin/mountpoint 
/bin/mountpoint: elf32-ebl_arm

eu-objdump: cannot disassemble

Was the bfd's (or binutils, I forget which) options not set to include *-arm?

Not a big deal, with dropbear once again running, I can scp to/from my desktop for using readelf / objdump on binaries.

(the utilities I built on my desktop fall into the category: "If the binary is for something that used/uses electricity - I can deal with it.")

Same problem with eu-objdump on recent (5.6.x) firmware and devices.

[NiLuJe]

Yep, cf. my last edits. Doesn't work on my desktop either, so, perfectly normal .

Which means that binary is currently pretty useless, .

[NiLuJe]

... Okay, I'm going nuts over here.

So, I spent the weekend wondering why my GCC 5.3-based ToolChains were completely b0rked. Since it's been a few months, and I couldn't find any real complaints, I decided to try to build one 'the Linaro way' (i.e., using Linaro's ABE tool, and not crosstool-ng).

After battling half-implemented features and outdated documentation, I got it to build me something useful. But, key factor: given the fact that you cannot apply patches to any of the components involved in the build (you instead have to feed it a local git repo, or setup a whole tarball fileserver), I only got it to build against Glibc 2.20...
And, surprise, that one generated *working* binaries.
(For those not following at home, the Kindles moved to Glibc 2.19 with FW 5.6.5, so I wasn't that cocnerned about the glibc bump yet).

Cue a moment of headscratching, followed by a series of regression testing with crosstool-ng... After 9 rebuilds of a PW2 TC (good thing that only takes 9 minutes on my beastly desktop...), I finally got to the root issue: building the TC against anything < glibc 2.19 results in broken code.

That's unfortunate, and weird as hell, since GCC is supposed to support glibc > 2.4. But, hey, whatever, I'll deal with that, I'm used to it with the K3 TC by now...

But it's not over yet... For a while now, my KOReader builds have produced a broken CRe library... With a hard-to-pinpoint segfault reminiscent of the behavior I experienced with the broken 5.3 TC.
So, since I was now using an apparently 'fixed' GCC 5.3 TC built against Glibc 2.19, and that my Kindle is up to date, I said, what the hell, let's try this...

And, yeeeeep, got something that worked perfectly well.

So I said, heh, cool, let's try to make that backwards compatible with Glibc 2.12... A few CFLAGS tweaks later, mission accomplished!
... except in that one, CRe crashes again.

ARRRRRRRGH.

[NiLuJe]

... Oh, wait. I'm stupid.

I had an empty sysroot for that working KOReader build. Now I don't.

This is starting to smell like an ABI mismatch, yum.

[knc1]

Linaro tc defaults to hard float IIRC.

[NiLuJe]

@knc1: Possibly, but I wasn't using one of their binary releases, I built a softfloat one using their build tools . (Target selection, at least, worked as advertised ^^).

[NiLuJe]

#winning \o/

Works much better without stray -L & -isystem flags in my env. -_-".

[knc1]

Originally Posted by NiLuJe

@knc1: Possibly, but I wasn't using one of their binary releases, I built a softfloat one using their build tools . (Target selection, at least, worked as advertised ^^).

I have been having nothing but toolchain troubles these past few days myself.

I'll give that thing a try. (arm-native to arm-native)

I have a Debian arm/Jessie chroot that is working trouble free.
But Debian arm-native toolchains, new and old, are nothing but trouble.

[knc1]

Note: Linaro seems to assume abe is running on an Intel machine, rather than an ARMel.

[NiLuJe]

There, pushed both sets of updates .

KOReader should now be fully functional.
And the objdump/readelf issue has been resolved by using binutils when appropriate .

[knc1]

I was beginning to think I would have to re-write parts of configure.ac ...
But with poking and prodding -
NOTE: Buildall: Building "infrastructure binutils stage2 libc gdb" for native target armv7l-unknown-linux-gnueabi.

Maybe I should have changed that tuple to:
armv7l-kindle-linux-gnueabi

[geekmaster]

Is amazon hinting at something?
http://www.amazon.com/Violated-By-Mo.../dp/B015RLOWW8

[knc1]

Originally Posted by NiLuJe

@knc1: Possibly, but I wasn't using one of their binary releases, I built a softfloat one using their build tools . (Target selection, at least, worked as advertised ^^).

To get the build system to do all of its tricks, you really need LSB installed.

The script that abe ships has:

LSB_ARCH="x86_64"
LSB_VER="4.1"

hardcoded.

The releases are shipped as *.rpm packages (groan).

But abe requires that you have alien installed (and complains if you don't, so I suppose you do).
(And if you really, really hate alien, I have a bash script that will open *.rpm packages - but I think libarchive will also)

Since I am working on a 32-bit / *.deb system . . . .

Long story short -
I attach here the LSB release tree layout as pseudo code.

I.E: A more general system's support could be scripted - but I probably never will.

( I am going to download the five archives I need at the moment and let the rest of the world deal with this on their own terms.)

[NiLuJe]

@knc1: I happen to have lsb-release installed (it's a mumble dep, IIRC) .

I do not have alien & co, though, but I did catch the configure script complaining about it. I don't think it matters unless you actually want to build deb or rpm packages of the binary TC.

And, yeah, libarchive (or p7zip) can handle rpm & deb just fine . There's also an eclass in Gentoo that handles those through more conventional tools (IIRC, there's cpio involved somewhere in one or both of those).

[knc1]

Originally Posted by NiLuJe

@knc1: I happen to have lsb-release installed (it's a mumble dep, IIRC) .
- - - -

lsb-release is about 970Mbytes too small

I now have the three lsb packages the abe scripting was asking for in a single archive (*.txz) - it is shrunk down to about 187Mbytes.
That is, lsb-4.1-x86 flavor (which, on inspection, also includes all releases 3.0 .. 5.0 - they just change some symlinks).