Porting Ethereum to mobile Linux

Last week the ETHDEV team made the decision to implement Ethereum Light Client as a sub-protocol, rather than as part of the main protocol. PV63 and PV64 will be dropped, and the work-in-progress has been ditched. The decision makes sense, to manage risk, and to separate concerns, but it delays things. Probably by about two weeks.

It is going to take some time for the dust to settle and for the client implementations to get back to working proof-of-concept on that still-to-be-defined sub-protocol. So Anthony and I are going to go off on a tangent for the time being, and focus on porting the existing full-node clients (both eth and geth) to all of the mobile Linux platforms of interest.

A new Ethereum Porting Gitter channel has been created, which I have written this "state of play" article for.

We are going to work on the following platforms and devices:

John Gerryts has been doing a very similar task for the last few months as part of a DEVGrant for EthEmbedded. His focus so far has been on compiling on-platform. This challenge has mainly laid in broken dependencies and in working through oddities in the specific platforms. The SBCs are all "just" Linux distros.

Mobile operating systems are rather different beasts than the capable little general computers which John has been porting Ethereum to. Mobile devices have usually been designed for running applications on, not building and developing applications on. There has been a major asymmetry between the power and specifications of desktop machines and mobile devices. There still is some asymmetry, but the gap is closing fast.

You don't develop iOS applications on an iPhone. You develop them on a Mac with a cross-compiler. You don't develop Android applications on an Android phone. You develop them on a PC, Mac or Linux box with a cross-compiler. Most mobile devices have never had enough memory or processing power to build anything substantial. The setup has been very similar to that which I have used for the majority of my professional development career building PlayStation and XBOX games. You develop on a desktop machine and build binaries to transfer to the target machine and then use a remote debugger.

That time is coming to a close. We are seeing a convergence across all device form-factors. All computing devices are good now. They nearly all have multiple cores, decent amounts of memory, network connectivity, ARM or x86 SoCs and are all much-of-a-muchness in their "form". There isn't much reason left why you wouldn't use your phone for software development, or even your watch in a few years time. I want to push the envelope on that, which is why I asked Anthony to start with looking at native builds on these devices. That didn't work so great for Tizen, and he will blog about that, but it looks to be a workable approach for Sailfish and Ubuntu Touch, which are very "normal" Linux distros.

Tizen native builds

Raster says: Tell him to cross compile. Tizen 2.x on things like emulator is for running tizen apps and nothing more. You will not fix tizen 2. All devices locked down. No root for you. You could cross build a toolchain for $home But you will need magic to get headers and other things working in home when the bins are in usr. But rpms won't help you. You need root. Emulator not useful as its x86. So you get gcc on it. Fine. Bins you make won't work on any shipping tizen device (worth noting). Rpi2 or other boards are a better bet imho

Sailfish native builds

Carsten Munk says: I'd for most purposes recommend a chroot on the device for compilation. you can for most intents and purposes take the ARM target of sailfishos and chroot into it on device. we have a couple of funny package dependencies that if you start developing a little too hard, device won't boot up, so ;)

Ubuntu native builds

Niklas Wenzel says: Every program available in the Ubuntu archives for the armhf architecture can be run on your phone (though you are going to run into issues with GUI programs). I've been compiling my stuff on my phone for quite some time now. However, the cross-compilation setup for Ubuntu SDK apps is really straight forward and way more comfortable than any compilation on the phone itself. Additionally, installing additional debian packages on the phone requires a writable system image which means that your phone can break when you install OTA updates in the future. (To prevent that, you can reflash the phone to its previous state with a read-only system partition but that also means that the additional packages you installed will be removed from the phone again.) You could also set up a chroot on the phone for compiling stuff though.

Cross-compilation of geth and eth.

Péter Szilágyi who works on Ethereum is also the author of xgo and has put together Wiki pages on Cross-compiling Ethereum and Ethereum on Android, as well as adding cross-compile targets into the go-ethereum makefile for us today. That is all cross-compilation for go. Niklas Wenzel was also kind enough to point us at his template for Go QML cross-compilation.

Cross-compilation of C++ for the eth client will be much simpler, given that C++ cross-compilation is the default for all of these mobile Linux platforms.

So lots of work to do. Anthony is digging in. When we have got everything working to the degree in which that is possible (native/cross * eth/geth * Tizen/Sailfish/Ubuntu) plus a few OS version variants, we can move on to look at where we are sitting compared to John's SBC builds. Hopefully we can come all of this work into some cohesive whole and maybe even upstream it all into the main C++ and go client repos. We will see :-)

I also want to set up an automated build farm for all of this hardware, using real devices, not emulators. And maybe we can even do some automated testing too.

When all of that is done, I hope we will be ready to go with actual Light Client code-paths within those applications we can now build for so many different platforms. We should also look at in-process execution for the go codebase (as already exists with libethereum) for inclusion within applications and on small IoC devices.

Stay tuned!