NOTE: You can follow along with our day-to-day progress on the Ethereum Porting Gitter channel.
Some progress! On both fronts: go-ethereum and cpp-ethereum.
Our efforts lately have been focused on cross-compiling these two projects targeting an
The easier one first. As Bob mentioned in his latest post, Péter Szilágyi from the go-ethereum team has created the great xgo tool, that allows cross-compiling go-ethereum to different platforms (though it is not limited to cross-compilation for Ethereum, it is a general tool).
Using xgo and the instructions from its README file, I was able to generate a binary for geth quite easily and without any change (xgo notably leverages the power of Docker). I was then able to run this binary on a Samsung TM1 developer phone (with Tizen O.S.), a process I will detail in an upcoming post. The binary worked well up until a point during block synchronization (~block 90K) where it failed, though nothing indicated it was an issue with the platform itself (more likely the particular version of geth I had used for compilation). I will rebuild and report on the result soon!
tony:~/tizen-sdk/tools $ ./sdb push ~/.tony/program/go/go1.4.2/bin/geth-linux-arm /home/developer pushed geth-linux-arm 100% 19MB 1 file(s) pushed. 0 file(s) skipped. /home/tony/.tony/program/go/go1.4.2/bin/geth-linux-arm 4142 KB/s (20639213 bytes in 4.865s) tony:~/tizen-sdk/tools $ ./sdb shell sh-4.1$ cd /home/developer/ sh-4.1$ ls geth-linux-arm testupload.txt sh-4.1$ ls -l total 20160 -rwxr-xrwx 1 developer developer 20639213 Sep 29 18:49 geth-linux-arm -rwxrwxrwx 1 developer developer 0 Jul 3 16:55 testupload.txt sh-4.1$ ./geth-linux-arm ======================================= Disclaimer of Liabilites and Warranties ======================================= THE USER EXPRESSLY KNOWS AND AGREES THAT THE USER IS USING THE ETHEREUM PLATFORM AT THE USER’S SOLE RISK. THE USER REPRESENTS THAT THE USER HAS AN ADEQUATE UNDERSTANDING OF THE RISKS, USAGE AND INTRICACIES OF CRYPTOGRAPHIC TOKENS AND BLOCKCHAIN-BASED OPEN SOURCE SOFTWARE, ETH PLATFORM AND ETH. THE USER ACKNOWLEDGES AND AGREES THAT, TO THE FULLEST EXTENT PERMITTED BY ANY APPLICABLE LAW, THE DISCLAIMERS OF LIABILITY CONTAINED HEREIN APPLY TO ANY AND ALL DAMAGES OR INJURY WHATSOEVER CAUSED BY OR RELATED TO RISKS OF, USE OF, OR INABILITY TO USE, ETH OR THE ETHEREUM PLATFORM UNDER ANY CAUSE OR ACTION WHATSOEVER OF ANY KIND IN ANY JURISDICTION, INCLUDING, WITHOUT LIMITATION, ACTIONS FOR BREACH OF WARRANTY, BREACH OF CONTRACT OR TORT (INCLUDING NEGLIGENCE) AND THAT NEITHER STIFTUNG ETHEREUM NOR ETHEREUM TEAM SHALL BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY OR CONSEQUENTIAL DAMAGES, INCLUDING FOR LOSS OF PROFITS, GOODWILL OR DATA. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF CERTAIN WARRANTIES OR THE LIMITATION OR EXCLUSION OF LIABILITY FOR CERTAIN TYPES OF DAMAGES. THEREFORE, SOME OF THE ABOVE LIMITATIONS IN THIS SECTION MAY NOT APPLY TO A USER. IN PARTICULAR, NOTHING IN THESE TERMS SHALL AFFECT THE STATUTORY RIGHTS OF ANY USER OR EXCLUDE INJURY ARISING FROM ANY WILLFUL MISCONDUCT OR FRAUD OF STIFTUNG ETHEREUM. Do you accept this agreement? [y/N] y I1004 23:21:26.410705 9630 flags.go:414] WARNING: No etherbase set and no accounts found as default I1004 23:21:26.411956 9630 database.go:71] Alloted 16MB cache to /home/developer/.ethereum/chaindata I1004 23:21:26.454467 9630 database.go:71] Alloted 16MB cache to /home/developer/.ethereum/dapp I1004 23:21:26.475128 9630 backend.go:291] Protocol Versions: [62 61], Network Id: 1 I1004 23:21:26.476165 9630 backend.go:333] Blockchain DB Version: 3 I1004 23:21:26.480377 9630 chain_manager.go:248] Last block (#0) d4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3 TD=17179869184 I1004 23:21:26.546630 9630 cmd.go:125] Starting Geth/v1.2.0/linux/go1.5.1 I1004 23:21:26.547729 9630 server.go:311] Starting Server I1004 23:21:26.568572 9630 udp.go:207] Listening, enode://firstname.lastname@example.org:30303 I1004 23:21:26.569580 9630 backend.go:559] Server started I1004 23:21:26.570892 9630 ipc_unix.go:109] IPC service started (/home/developer/.ethereum/geth.ipc) I1004 23:21:26.571563 9630 server.go:552] Listening on [::]:30303 I1004 23:21:26.574707 9630 nat.go:111] mapped network port udp:30303 -> 30303 (ethereum discovery) using NAT-PMP(192.168.1.1) I1004 23:21:26.588775 9630 nat.go:111] mapped network port tcp:30303 -> 30303 (ethereum p2p) using NAT-PMP(192.168.1.1) I1004 23:21:36.715515 9630 downloader.go:275] Block synchronisation started meanwhile: sh-4.1$ pwd /home/developer/.ethereum sh-4.1$ find . ./nodes ./nodes/000001.log ./nodes/LOCK ./nodes/LOG ./nodes/MANIFEST-000000 ./nodes/CURRENT ./geth.ipc ./nodekey ./chaindata ./chaindata/LOG.old ./chaindata/MANIFEST-000008 ./chaindata/LOCK ./chaindata/000010.ldb ./chaindata/LOG ./chaindata/CURRENT ./chaindata/000007.log ./dapp ./dapp/000002.log ./dapp/MANIFEST-000003 ./dapp/LOG.old ./dapp/LOCK ./dapp/LOG ./dapp/CURRENT sh-4.1$ find -type f | tr "\n" "\0" | du -cs --files0-from=- 1392 ./nodes/000001.log 4 ./nodes/LOCK 8 ./nodes/LOG 8 ./nodes/MANIFEST-000000 8 ./nodes/CURRENT 8 ./nodekey 8 ./chaindata/LOG.old 8 ./chaindata/MANIFEST-000008 4 ./chaindata/LOCK 1892 ./chaindata/000010.ldb 8 ./chaindata/LOG 8 ./chaindata/CURRENT 892 ./chaindata/000007.log 4 ./dapp/000002.log 8 ./dapp/MANIFEST-000003 8 ./dapp/LOG.old 4 ./dapp/LOCK 8 ./dapp/LOG 8 ./dapp/CURRENT 4288 total
Much more manual work here, but after much struggle I was able to successfully cross-compile the libweb3core library. I created a set of scripts that should allow anyone to reproduce this process (in fact please do and report on any issue encountered!).
For it to work, I had to use a number of hacks along the way however:
- code – Hardcoding Boost‘s
project-config.jamfile to use my gcc cross-compiler (I tried many different flags/environment variables for
bootstrap.shbut none ever worked/were picked up)
- code – Commenting out the CXXFLAGS
-march=nativeflags from CryptoPP‘s Makefile. Likewise I found no cleaner way to unset this flag (which you must for it to succeed).
- code – I was never able to get the
ARCHIVE_INSTALLS_DIRflag to get picked up during configuration for JsonCpp, instead having to rely on
DESTDIRduring the installation phase (not necessarily a big issue, but still frustrating)
- I ended up having to create a
~/$HOME/cryptoppsymlink to CryptoPP’s installation directory for libweb3core‘s CMake file to be able to detect CryptoPP’s headers, no other combinations ever seemed to work. This on top of making
CMAKE_INCLUDE_PATHpoint to the source directory. Removing either results in a failure to detect said headers (note that no such issue occured for the detection of the library itself).
- code – Disabling of MiniUPNP, which has apparently broken backward compatibility in its latest version and for which I wasn’t able to find a working version (typically because of failure to include
upnp-dev.h, which would have also required hacking their CMake file).
- code – Removal of erroneous
-lOFFartifacts from the CMake configuration phase of
libweb3core, a bug I have brought to the attention of the
If anyone is aware of workarounds for these or can even suggest a more straighforward/correct way of getting to the same result, please contact me on gitter.
So overall it’s quite a lot of pieces that need to work together in order to create such a binary. Next step will be building other necessary components for eth to run. After which I will hopefully be able to test the C++ client on the same Z3 phone!
Stay tuned for more progress!