Minor QoL tweaks for easier installation #6
Conversation
In order to link against the STL dynamically there (Also, use -static-libstdc++ instead of a much harsher -static).
NiLuJe
changed the title
|
(I actually tried the KFMon script and a GCC 4.9 build, everything looks fine ;)). |
| # Attempt to automatically drop -static-libstdc++ when using the Nickel TC... | ||
| ifeq ($(shell PATH='$(PATH)' $(CROSS_TC)-gcc -dumpmachine 2>/dev/null), arm-nickel-linux-gnueabihf) | ||
| STATIC_STL_FLAG:= | ||
| # What can I say, it's old... |
There was a problem hiding this comment.
To be fair, the Kindle rootfs is also ridiculously old (and softfloat), the PocketBoot rootfs has only recently been updated, and it's not terribly fresh either.
reMarkable seem to care a bit more about these things, they're using a fairly recent rootfs, as well as slightly less old kernels (given the NXP constraints when targeting an i.MX6/i.MX7 board).
| - `koboroot/inkvt.png` to `/inkvt.png` | ||
| - `koboroot/inkvt.ini` to `/.adds/kfmon/config/inkvt.ini` | ||
| Then, in a standard USBMS session, unpack the `InkVT-*.zip` archive to the root of your Kobo device. | ||
| Eject & unplug it safely, and let it process the new InkVT "book". |
There was a problem hiding this comment.
A .zip might indeed be a lot easier installation method
There was a problem hiding this comment.
The salient point being that you need an USBMS session for nickel to "scan" new content (even a reboot won't do that), so doing it this way usually means that requirement automatically gets met ;).
(That's only relevant if you want the KFMon integration to work, i.e., on a first install. Otherwise, just pushing stuff over SSH will do just fine ;)).
|
Build works flawless, including already existing other binaries 👍 |
Mainly by automating the creation of a properly laid-out ZIP ;) (re #4 & #5).
Also, clear up the TC shenanigans in the doc, and detect and handle a "matching" TC (i.e., nickel's).