Weather Kindle: packaging advice needed

[scolby33]

Hello! I've created a cool program (hack?) for my old K4NT and need some advice on packaging it up for easier installation by others.

You can see all the details here on Github, but, in a nutshell, it downloads the weather forecast for your area over Wi-Fi and displays it on the Kindle, all without any external server--the Kindle does all the work!

I have a semi-reasonable installation process worked out, but I'd like to package up the whole thing as an Update_whatever.bin and perhaps make sure it works on other Kindles than just the K4NT.

I also need advice on how to set the LD_LIBRARY_PATH automatically--if I symlink the binaries I need to /usr/bin (like I see things like USBNetwork doing), how do they know to find their .so's in /usr/mnt/whatever/lib? Will this require re-compiling the binaries?

Finally, I'd like to add KUAL compatibility, which doesn't look to be too difficult, but any advice on potential landmines would be welcome.

[knc1]

Display the rpath entry in the USB net elf binaries - that is how it happens.
LD_LIBRARY_PATH changing is not required.

You do not need to re-compile your binaries, you can use patchelf to change the library path.
patchelf is posted here, both for x86 and armel.

Use the most recent KindleTool from the snapshot thread, that does the packaging.
Be certain to RTFM on KindleTool.

There is no such thing as KUAL compatibility - if the target is executable on armel (or S360), it is compatible.

The K4 was the last Kindle to NOT use X11 in the 'main' OS (K4 'diags' runs X11).
The K4 was a transition device in a lot of ways.
So get your application running on one of the firmware 5.x devices next.
(This is Amazon sales week - a good time to buy. The KT3 (unlighted screen) is the cheapest and includes Bluetooth support. The PW3 (front lit screen) is the best deal for the money. The others are for the "Bragging Rights" people.)

It is an "after market add-in".
'Hack' is a four letter word, this is a public forum, be nice.
(For an explanation, click link in my signature.)

[scolby33]

Thanks for the info about patchelf! I managed to get pngcrush working, but not rsvg-convert:

$ patchelf --set-rpath /mnt/us/weather/lib rsvg-convert
$ patchelf --set-rpath /mnt/us/weather/lib pngcrush
$ readelf -d rsvg-convert | grep RUNPATH
 0x0000001d (RUNPATH)                    Library runpath: [/mnt/us/weather/lib]
$ readelf -d pngcrush | grep RUNPATH
 0x0000001d (RUNPATH)                    Library runpath: [/mnt/us/weather/lib]

It turns out that all of pngcrush's shared libraries are already in /usr/lib, but I was able to confirm that it was searching the RUNPATH by touching one of the libraries in my lib folder and getting an error:

# pngcrush --qf -c 0 img/error.png img/e.png
pngcrush: error while loading shared libraries: /mnt/us/weather/lib/libpng12.so.0: file too short

However, no matter what I've tried, I can't get rsvg-convert to search it's RUNPATH:

# rsvg-convert
rsvg-convert: error while loading shared libraries: libgsf-1.so.114: cannot open shared object file: No such file or directory
# ls /mnt/us/weather/lib | grep libgsf
libgsf-1.so.114

Any hints or ideas about what's happening?

[knc1]

Use the information found in this thread:
https://www.mobileread.com/forums/sho...86&postcount=6
And before/after - I was inventing the ARMhf on Kindle as I went along.

In particular, see the following post (#7) for a worked example of how to get the dynamic loader to report the paths it is searching.

You are not using ARMhf (although you may have copied one by accident) but all the utilities and debugging process is the same as I used in that thread.

[scolby33]

I got it! The difference between RPATH and RUNPATH was the issue, and the most recent version of patchelf seems to greatly prefer the latter...I couldn't ever get it to set RPATH.

librsvg-2 needs libgsf-1, so I just patched librsvg's RUNPATH and everything works great now.

Is it typical practice to patch all the binaries and shared libraries, or only those that complain?

I haven't been able to find documentation on this, but from looking at examples, the Kindle runs the file "install.sh" when unpacking an update?

[knc1]

IIRC - Yes it does.
The dummy update package is suppose to be the worked example.

Another thing which is possible with patchelf -
Make the entire application behave like a Windows application -
Put both the executable and all the required libraries that are not already in /lib, /usr/lib in the same directory.
Include:
$ORIGIN
Exactly like the above including the '$' first in rpath (note that patchelf is actually setting runpath, they just kept the original terminology).

Then, just like the Windows dynamic loader, ld.so will first search the directory that holds the executable.

You can also use paths relative to $ORIGIN -
Here is what one example looks like (cvm - the Kindle's Java VM):

Dynamic section at offset 0xab4 contains 30 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED)                     Shared library: [libpthread.so.0]
 0x00000001 (NEEDED)                     Shared library: [libjli.so]
 0x00000001 (NEEDED)                     Shared library: [libdl.so.2]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]
 0x0000000e (SONAME)                     Library soname: [lib.so]
 0x0000000f (RPATH)                      Library rpath: [$ORIGIN/../lib/arm/jli:$ORIGIN/../lib/arm]

Note that it has an soname, even though it is called as an executable.
That is to allow external, dynamically loaded, libraries call back into it.
You can see that it also uses libdl (the dynamic library loader).
So it also loads other libraries ('plugins' in some languages) -
All-in-all, probably one tricky bit of coding in that application, that is about as complex as an ELF format file can get.

- - - -

I am not intentionally feeding you bits and pieces of the answer -
I am only remembering bits and pieces at any one time -
Age does that -
There are members of this site older than myself, but very few of them.

[iXPert12]

Wow. Actually i was working on this too, based on cathay4t's kindle-weather github page and Niluje's python libs. As for dependencies for pngcrush and rsvg-convert , i renamed the libs using their symlink name and copied them into /usr/lib/ as a temporary solution. Then i modified the weather svg to match PW1 resolution.
I got stuck at the power management. I didn't want to keep my kindle usb connected all the time, so i wanted a solution to create a loop that wakes up kindle every 30-60 minutes and updates the weather and then put it to sleep/low power mode. After a lot of investigations, i found https://github.com/snowtechblog/avakindle that may give a solution using rtcwake. But i put on hold this project for now.

[knc1]

Originally Posted by iXPert12

Wow. Actually i was working on this too, based on cathay4t's kindle-weather github page and Niluje's python libs. As for dependencies for pngcrush and rsvg-convert , i renamed the libs using their symlink name and copied them into /usr/lib/ as a temporary solution. Then i modified the weather svg to match PW1 resolution.
I got stuck at the power management. I didn't want to keep my kindle usb connected all the time, so i wanted a solution to create a loop that wakes up kindle every 30-60 minutes and updates the weather and then put it to sleep/low power mode. After a lot of investigations, i found https://github.com/snowtechblog/avakindle that may give a solution using rtcwake. But i put on hold this project for now.

Do not modify the Amazon image, you are asking for trouble.
Set the library search path (rpath) in your executable to give the path to your libraries.

PS:
You can find the original development of avakindle in this forum.
I guess this is just another example of running out of bytes when it came to giving credit where credit is due.