Quote:
Originally Posted by pazos
Most of the stuff you're planing to do is useless. All kobos from Kobo Touch onwards (with fw: > 2) share the same ABI: armhf, which is already supported by alpine.
About building them natively instead of cross compiling: it is painfully slow and won't work for huge packages. The build system will require a few GB of RAM available to build them and will start to swap to disk a LOT wearing your internal storage or just go OOM if there's no swap enabled.
Building packages natively won't help to make them work if that's happen because a specific kernel in a specific FW for a specific device lacks a feature, like devtmpfs, that your rootfs is going to use.
My suggestion: update your Mini FW to latest tested version (4.x). It should have a "modern" kernel with features on par with other boards. Busybox shouldn't segfault there.
|
I've already considered all of this stuff, upgraded my Mini and all, but the update doesn't bump the kernel, which is stuck at 2.6.35.3.
Building latest BusyBox doesn't cause a segfault when the natively-compiled version is run, and I wrote a bootstrap script (
https://github.com/Alpine-KoBox/bootstrap) that permits you to do it right on your device, unattended.
For QtWebKit/Engine, strangely it works on some devices (like the Mini and the Glo HD) but fails on other devices (like Libra or Aura H2Ov2), probably due to the kernel version. As you can see here (
https://www.youtube.com/watch?v=RsWvQx4QAEY), Falkon had no problem rendering a YouTube video on my Glo HD.
Any clue why? thanks
Also related to cross-compiling, I might shift to that for larger packages (like GCC), but most of the development (when possible) will be done directly on the device for optimization/compatibility reasons.
but thanks for your advice!
p.s.: I've tried NetSurf on my main Linux PC and it doesn't keep up with the current standards, making it difficult to display modern webpages.