Support armhf

[anthony-cros]

No description provided.

[bobsummerwill]

Do you mean more platforms (ie. build for Sailfish, Ubuntu Phone)? Or are you specifically thinking ARM vs i386 here? So the scripts can be used for SBCs.

[bobsummerwill]

See https://doublethinkco.wordpress.com/2015/09/22/porting-ethereum-to-mobile-linux/ for target platforms (all ARM).

The list at https://doublethinkco.wordpress.com/ethereum-light-client/ includes the SBCs. The Intel Edison is the only i386 one for now, though I have an Intel NUC as well, which I would like it to work for.

So in general, I think i386 is very low priority for now.

[bobsummerwill]

Hey @phonikg! Actually, maybe this is a task which would make sense for you to look at? Or are all your DEVgrant target platforms ARM too? Have you tried using webthree-umbrella-cross yet?

[anthony-cros]

Yes the idea was to explore other architectures like i386 or whichever ones would make sense, i think these scripts can be leveraged easily to do that as they're quite generic already except in a few places like here or here

[bobsummerwill]

So yeah, i386 and amd64 are probably the only ones really worth considering.

Also maybe armhl as well as armel might be needed. I get a suspicion that either Tizen or Sailfish is actually a different ARM variant than Android. Will have to dig into that.

Beyond x86 and ARM though? Balls to them.

[bobsummerwill]

armhf, I mean.

[phonikg]

Yeah @bob all EthEmbedded boards are armhf. I was always thinking on Intel Edison x86 as a bonus but Christoph from Slock.it has that running already no no sense in duplicating that work if they will share it.... my understanding is that they are compiling on device though, so an x86 cross compilation would still be extremely helpful.

[bobsummerwill]

Thanks @phonikg. And you are specifically building armhf for your existing binaries? Or perhaps that is just happening by default?

[bobsummerwill]

Also, @phonikg.

With this existing setup, I've just been able to build myself an ARM binary on a VM in Azure. So I think we are very, very close to a "done" point, where we are iterating and bug-fixing on something which is functional.

Have you tried the Dockerfile yet yourself? If not, please do give it a whirl.

just git clone, docker build and then docker run -i -t /bin/bash to then do the actual build.

[anthony-cros]

@phonikg , you can even just do docker build . if you're in the folder containing the Dockerfile :)

[phonikg]

While we are all working away at testing, and due to the fact that I have not been able to follow through and get a binary yet at this point, would you be able to provide me with any binaries you guys have been able to create?

Email me a link even, so I could download and try running on a few arm devices?

[phonikg]

NVM!! @bobsummerwill posted this an hour ago:(

https://github.com/doublethinkco/webthree-umbrella-cross/releases

[bobsummerwill]

@phonikg and @martinbrook: So it might be a simple as building the xcompiler with arm-unknown-linux-gnueabihf.

This is the other line I was thinking of which @anthony-cros had mentioned as a hack, but might be OK in this instance for armhf ...

https://github.com/doublethinkco/webthree-umbrella/blob/develop/cross-build/ethereum/boost.sh#L26

Maybe there are more little warts like this? Or maybe not!

[anthony-cros]

So it might be a simple as building the xcompiler with arm-unknown-linux-gnueabihf

yes I suspect it will be necessary now, in light of all the recent findings

[bobsummerwill]

Lots of related ARM ABI discussion happening in #21.

[anthony-cros]

Sadly, there doesn't seem to be an explicit option for armel in crosstool-ng:

$ ../ct-ng list-samples | grep arm-unknown-linux-gnueabi
    [G..]   arm-unknown-linux-gnueabi
$ ../ct-ng list-samples | grep -i el
    [G..]   m68k-unknown-elf
    [G..]   mips-unknown-elf
    [G.X]   mips64el-n32-linux-uclibc
    [G.X]   mips64el-n64-linux-uclibc
    [G..]   mipsel-sde-elf
    [G..]   mipsel-unknown-linux-gnu

[anthony-cros]

now i understand we can create such "sample" ourself (some kind of a profile I believe)

[anthony-cros]

samples present themselves that way:

~/crosstool-ng-1.20.0/samples/arm-unknown-linux-gnueabi$ cat crosstool.config 
CT_LOCAL_TARBALLS_DIR="${HOME}/src"
CT_SAVE_TARBALLS=y
# CT_REMOVE_DOCS is not set
CT_LOG_EXTRA=y
CT_ARCH_FLOAT_SW=y
CT_ARCH_arm=y
CT_KERNEL_linux=y
CT_BINUTILS_LINKER_LD_GOLD=y
CT_BINUTILS_GOLD_THREADS=y
CT_BINUTILS_LD_WRAPPER=y
CT_BINUTILS_PLUGINS=y
CT_LIBC_glibc=y
CT_CC_LANG_CXX=y
# CT_CC_GCC_SJLJ_EXCEPTIONS is not set
CT_DEBUG_dmalloc=y
CT_DEBUG_duma=y
CT_DEBUG_gdb=y
# CT_GDB_CROSS_PYTHON is not set
CT_GDB_NATIVE=y
CT_DEBUG_ltrace=y
CT_DEBUG_strace=y

and

~/crosstool-ng-1.20.0/samples/arm-unknown-linux-gnueabi$ cat reported.by 
reporter_name="Alexander BIGGA"
reporter_url="http://sourceware.org/ml/crossgcc/2008-06/msg00031.html"
reporter_comment=""

[phonikg]

Hopefully its as simple as CT_ARCH_FLOAT_SW=n

[anthony-cros]

I was wondering too, but i doubt it :)

what other differences do you know of between hf/el? can float really be the only one?

[phonikg]

I believe its simply software vs hardware based floating point. This opinion is based mainly on this article:

https://blogs.oracle.com/jtc/entry/is_it_armhf_or_armel

[anthony-cros]

I think its saying it can't link this library with pthreads as pthreads is not compiled -fPIC

thanks @martinbrook , you're probably right actually

[anthony-cros]

getting @anthony-cros's local edits

to be committed soon, it's actually quite small

tweaking around with these libraries version and ABI settings to get each platform happy in-turn

that's going to be the trickier part, but I'll make a convenience function. I'm hoping to make it open-close-principle friendly so everyone can just extend a baseline script.

Let's close this issue when you have committed your armhf changes

sounds good

[anthony-cros]

We should try those as an alternative to the ones we are currently building ourselves with crosstool-NG

do you need me to try on the TM1 too?

[anthony-cros]

I'll make a convenience function. I'm hoping to make it open-close-principle friendly so everyone can just extend a baseline script.

==> 210dcbd

[bobsummerwill]

do you need me to try on the TM1 too?

Try to your cross-built armhf binary on the TM1? Yes, please! It might "just work". #20 is now tracking Tizen support specifically, so that would be the place to put that result.

So to get this working for me, I am going to need to make an extra Dockerfile, right? Which passes an extra parameter pointing to an armhf config?

[anthony-cros]

Try to your cross-built armhf binary on the TM1?

no i meant the apt-get install g++-arm-linux-gnueabi/apt-get install g++-arm-linux-gnueabihf combination, sadly I already tried the armhf binary i created earlier, but no dice

[anthony-cros]

So to get this working for me, I am going to need to make an extra Dockerfile, right?

so you could reuse the current docker file for that, just pass along the parameter ("default" or "/my/path/to/my/config")

[bobsummerwill]

so you could reuse the current docker file for that
Right ... if we add some parameterization to the Docker file itself, which I think is possible?

[bobsummerwill]

@anthony-cros said - no i meant the apt-get install g++-arm-linux-gnueabi/apt-get install g++-arm-linux-gnueabihf combination, sadly I already tried the armhf binary i created earlier, but no dice

Replied in #42.

See also #20 (Support Tizen).

[anthony-cros]

Right ... if we add some parameterization to the Docker file itself, which I think is possible?

yes, at least with the -e flag for EVs, though possibly simply as an argument to docker-build if it's possible

[anthony-cros]

See b99d13a :)

[bobsummerwill]

WOOT! Nice one.

We still need you to upload your armhf xcompiler results, though, right?

Like updating Docker-eth to something like ...

RUN wget ‐‐output-document=x-tools.tar.gz https://github.com/doublethinkco/webthree-    umbrella-cross/releases/download/0.0.3/x-tools-armel.tar.gz; exit 0
RUN tar xvfz x-tools-armel.tar.gz
RUN wget ‐‐output-document=x-tools.tar.gz https://github.com/doublethinkco/webthree-    umbrella-cross/releases/download/0.0.3/x-tools-armhf.tar.gz; exit 0
RUN tar xvfz x-tools.armhf.tar.gz

[anthony-cros]

sounds good, i'm rerunning them and will upload!

[bobsummerwill]

Thanks!

I don't understand how YOU were able to run ./build-wandboard.sh yourself. Wasn't YOUR container missing the xcompiler files for unknown-arm-linux-gnuabihf too?

[anthony-cros]

oh no, I only ran the ./build-xcompiler-wandboard.sh one!

[bobsummerwill]

Ha ha!
Looks like the wandboard.tgz you uploaded is wrong too, eh? It's the build scripts, not the xcompiler files, not the eth.

[anthony-cros]

hmm i seem to be getting an error on upload, let me try again

[anthony-cros]

https://github.com/doublethinkco/webthree-umbrella-cross/releases/tag/wandboard.tgz

[anthony-cros]

a bit more work needed here actually

[anthony-cros]

see #53 for latest development

I'm getting this however, @bobsummerwill , could it be something you changed recently?

(CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/bash /home/crosseth/eth/wd/libmicrohttpd/missing autoheader)
/home/crosseth/eth/wd/libmicrohttpd/missing: line 81: autoheader: command not found
WARNING: 'autoheader' is missing on your system.
         You should only need it if you modified 'acconfig.h' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'autoheader' program is part of the GNU Autoconf package:
         <http://www.gnu.org/software/autoconf/>
         It also requires GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [MHD_config.h.in] Error 127

[bobsummerwill]

MERGED! And will do some runs and see where I can get to :-)

[bobsummerwill]

All good. I'm re-declaring this as done. Have uploaded new binaries to release. It's in a state where we can reliably produce armel and armhf binaries now, and start iterating on the ABI details.

[anthony-cros]

so it appears the ubuntu touch phone is armhf: ubuntu build description: ubuntu 15.04 - armhf, I didn't realize that earlier (I thought it was armel actually)