KindleTool: Create/Unpack Kindle update files

[PSGrabber]

No luck with v1.6.4.37. The result is the same

[NiLuJe]

Weird, I made a point of building w/ -march=core2 for just that reason... And I'm not aware of any of the components trying to be smart with CFLAGS, so, double-weird...

If you can, see if building it yourself via homebrew leads to a better result?

[PSGrabber]

I do not have homebrew installed and, probably, won't install it just for this purpose only. It would be much simpler for me to try a different machine with different OS. Nevertheless, many thanks for help

[NiLuJe]

@PSGrabber: Perfectly understandable .

If you could get me a backtrace of the SIGILL, I might be able to pinpoint if something's misbehaving, and/or if I simply expected XCode's clang to behave like GCC while it in fact does not.

[NiLuJe]

@PSGrabber:

I may have managed to make gmp behave and not try to target my own CPU, but the one I'm actually explicitly targeting, and thus not include highly cpu-specific assemby routines, so, does this build run on your machine?

[PSGrabber]

This time I get

Invalid number of supported devices (3) for this update type (OTA V1).

[NiLuJe]

@PSGrabber: With the exact same commandline as in your previous code block?

That's... weird (again ^^).

[PSGrabber]

exactly the same
Oh, no, not exactly - this time I used

-d kindle3

and this produces error. But it finally works when I change it to

-d k3w

Thus, only alias remains to fix, imho

[NiLuJe]

Does the number in parenthesis change, or is it always 3? (Try with other device names?).

That's a very simple piece of code (which works perfectly well everywhere else), so I'm going to assume that something is subtly corrupting memory somewhere when run on these CPUs, which I'll somehow chalk up to XCode and I'm not sure I can do anything about, but, still, interestingly weird ^^.

[PSGrabber]

I have edited my previous post

[NiLuJe]

@PSGrabber: Great!

Then good news all around: the alias isn't supposed to work, OTA V1 only supports a *single* target device (hence the mess of packages when distributing stuff for those devices. And unless you use MRPI, we have to stick to OTA V1 on those devices).

(The error message is slightly vague because it's used in a number of different situations, and the mess of tests in the if block is already beastly enough as it is ;p).

Thanks for your various tests, I'd never have thought that something was wrong on those CPUs since I thought I'd already done enough to support them .

[PSGrabber]

@NiLuJe: Many thanks for your great help and support

[NiLuJe]

Oh, joy, it's that time of the year again...

We'll see how that turns out, I guess...

[geekmaster]

The mingw x64 kindletool.exe fails when doing an extract, because x64 windows does not allow user apps to create files on the hdd root. I changed the win32 (& not cygwin) temp path from "" to "." to use the current dir instead of root. A github pull request is pending. I did not do a build (no toolchain installed here).

EDIT: It looks like I need to setup a toolchain on this computer. Proposing changes without testing them is relatively pointless.

EDIT2: Even yifanlu's older kindletool fails extract with "Cannot create temporary file." on my win7 x64. Time to use linux instead?

[NiLuJe]

@geekmaster: Yup, known issue. Not limited to x64, IIRC.

Running as a privileged account is the current workaround.

I'll check soon-ish if using $PWD helps.
If someone *really* cares, it should be done right w/ GetTempPathW... Which opens a whole n'other can of worms, because I currently royally disregard's Windows Unicode mess... (char vs. wchar_t). Which is also why, if you ever manage to get a libarchive error printed, it'll be mangled.