For ARM you need this file arm-kindle-linux-x-tools-glibc2.5-gcc4.2.4.tar.gz (45741995 bytes). Just unpack it's "arm-kindle-linux-gnueabi" subdirectory into /usr/local/arm and add /usr/local/arm/arm-kindle-linux-gnueabi/bin/ to PATH and everything will be OK. (compile with make HOST=arm-kindle-linux-gnueabi)

For emulator, on my system (FC12, 32bit) everything compiles fine, with no adjustments to the Makefile.

Just to add that the x-tools file is very hard to find, but you will find it in one of those "forbidden to even mention" places I have no idea why, but this fact prevented me from hosting it on my own site, just in case... The x-tools toolchain is preferable because it already contains the correct sysroot stuff for the Kindle, so you don't have to pick the libraries from Kindle's actual root manually.

And, btw, if you are interested in just a PDF/DjVu viewer (without builtin CoolReader) then you can build the kpdfdjview branch (git checkout kpdfdjview) which has fewer dependencies and builds much faster, resulting in a smaller program.

Also, to build an installable package you need to do "make HOST=arm-kindle-linux-gnueabi customupdate".

Last edited by tigran; 09-16-2012 at 06:52 AM.
Reason: added a few more advices

For ARM you need this file arm-kindle-linux-x-tools-glibc2.5-gcc4.2.4.tar.gz (45741995 bytes). Just unpack it's "arm-kindle-linux-gnueabi" subdirectory into /usr/local/arm and add /usr/local/arm/arm-kindle-linux-gnueabi/bin/ to PATH and everything will be OK. (compile with make HOST=arm-kindle-linux-gnueabi)

Thanks a lot. It's not that hard to find - I already had it, just didn't have a chance to try it out yet . I'll try a bit later and report back. Btw, make HOST=arm-kindle-linux-gnueabi is equivalent to just make with HOST=arm-kindle-linux-gnueabi in Makefile, right?

Quote:

For emulator, on my system (FC12, 32bit) everything compiles fine, with no adjustments to the Makefile.

Actually, I'm more interested in the emulator. I'll try another distro later, that's not a problem. What I want to know is if you find any faults with my steps.

Quote:

And, btw, if you are interested in just a PDF/DjVu viewer (without builtin CoolReader) then you can build the kpdfdjview branch (git checkout kpdfdjview) which has fewer dependencies and builds much faster, resulting in a smaller program.

I'm interested in all formats I get get , but it won't hurt to also try kpdfdjview branch too. Will try later.

Quote:

Also, to build an installable package you need to do "make HOST=arm-kindle-linux-gnueabi customupdate".

I knew this one (I took a look in Makefile), but as I understood it, this will only package it in zip - won't help if it doesn't compile in the first place.

And thank you for pointing me to VirtualBox! I know that my FC12 installation is ancient (and also, using 32bit OS on a 64bit machine is stupid, as I have to use PAE mode), but I have too many "mission critical" things (e.g. my entire typesetting environment for all the books I publish) which depend on it. So, now I can try the latest FC17/64bit and see if all my "mission critical" things still work on it and switch to it if all is fine. Thank you!

Btw, I am now installing FC17/64bit in VirtualBox and will then install the development environment for kindlepdfviewer in it, so I will let you know if it all went smoothly. Then you could just repeat the same on your machine.

Thanks a lot. It's not that hard to find - I already had it, just didn't have a chance to try it out yet . I'll try a bit later and report back. Btw, make HOST=arm-kindle-linux-gnueabi is equivalent to just make with HOST=arm-kindle-linux-gnueabi in Makefile, right?

"HOST" is usually computed or determined by the build system.

Usually when cross-compiling, you want to set: "TARGET=" which describes the system on which the generated code will execute.

knc1
In the case of kindlepdfviewer you do need to set HOST= manually when you run make, it is not "computed" by anything. And you don't need to set TARGET= either.

Kai771
Yes, you are right --- I just found out that on FC17 64bit one cannot run arm x-tools because of /lib/ld-linux.so.2 ELF interpreter issues. So, using VirtualBox saved me a lot of time and trouble attempting to switch to the latest 64bit OS --- now I know that I should stay with my old good FC12 32bit

But I like the VirtualBox idea... Is it portable? I.e. can I take my vdi files and use them on some other system using any OS (obviously installing VirtualBox software for that OS first)? Or is each vdi image bound to a specific host OS on which it was produced?

And the main achievement of today is that I don't need to dual-boot into Windows XP on my main machine any longer --- I can just install Windows 7 (or XP) inside VirtualBox and run all the Windows-specific programs (Mathematica, Matlab, yes, I know there are Linux versions but they don't really work) in it!

Also, just for completeness (maybe someone is curious) I should mention that even the emulator stuff cannot be compiled on a 64bit OS --- here the problems are easier (djvulibre just fails to compile, but surely it can be made to compile somehow, otherwise we would have no such thing as djview4 on 64bit) but still require work to fix, so it is easier to just stick to 32bit environment.

An extreme exception to the usual practice.
Must be someone's hand written Makefile.

In the case of a program written for a specific hardware and specific OS platform and which cannot be ported to a different OS or hardware, it is the "usual practice" to write Makefile by hand. And kindlepdfviewer fits this description perfectly.

In the case of a program written for a specific hardware and specific OS platform and which cannot be ported to a different OS or hardware, it is the "usual practice" to write Makefile by hand. And kindlepdfviewer fits this description perfectly.

Anything handwritten need only meet the author's own standards.
So no defense of that practice is required.

Yes, you are right --- I just found out that on FC17 64bit one cannot run arm x-tools because of /lib/ld-linux.so.2 ELF interpreter issues. So, using VirtualBox saved me a lot of time and trouble attempting to switch to the latest 64bit OS --- now I know that I should stay with my old good FC12 32bit

Or, if it's only kindle developement tools, there's no reason not to use 32bit FC17 (or 12) in a VirtualBox of 64bit FC17.

Quote:

But I like the VirtualBox idea... Is it portable? I.e. can I take my vdi files and use them on some other system using any OS (obviously installing VirtualBox software for that OS first)? Or is each vdi image bound to a specific host OS on which it was produced?

I can't be 100% sure, since I never tried that, but I see no reason why it shouldn't be. What I did try is exporting to .ova on Windows and importing that .ova in Linux without problems. Files are much smaller that way .

Now, back to kindle. I tried using x-tools and it failed. This is what I did:

Code:

$ tar xzvf x-tools-glibc2.5-gcc4.2.4.tar.gz

this made x-tools-glib2.5 dir, with arm-kindle-linux-gnueabi inside it. I did this next:

Why did I have an "arm" directory at all? Because I was trying different ARM toolchains and that was an easy way to switch between them. But you can skip "arm" level altogether and adjust PATH accordingly.

Thank you! I moved it to appropriate level, and now it compiles. As you suspected, the confusion was caused by the presence of 2 dirs with the same name, arm-kindle-linux-gnueabi. The PATH was ok from the beginning - it was just the wrong content there .

Previously the emulate mode compiled with no error in my Gentoo x64 machine. But it fails on my freshly installed x86 Ubuntu today. I modified the Makefile and now it works on my Ubuntu too. You may want to checkout the latest code from the official repo

Still I have no idea why it worked on my Gentoo before this modification. I just moved all the "-l" to the end of GCC call.

Previously the emulate mode compiles with no error in my Gentoo x64 machine. But it fails on my x86 Ubuntu. I modified the Makefile and now it works on my Ubuntu too. You may want to checkout the latest code from the official repo

Still I have no idea why it worked on my Gentoo before this modification. I just moved all the "-l" to the end of GCC call.

*-gcc -v might give you the answer.

Ubuntu (depending on the version and update level) recently "Borked" the built-in search path order for includes and libraries in an attempt to re-vamp the multi-lib / multi-arch support.