search

doublethinkco / cpp-ethereum-cross

Scripts for cross-building cpp-ethereum (C++ Ethereum client)
http://doublethink.co/
Apache License 2.0
27 stars 11 forks source link

Support armhf #10

Closed anthony-cros closed 8 years ago

bobsummerwill commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

armhf, I mean.

phonikg commented 8 years ago

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 commented 8 years ago

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

bobsummerwill commented 8 years ago

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 commented 8 years ago

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

phonikg commented 8 years ago

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 commented 8 years ago

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

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

bobsummerwill commented 8 years ago

@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 commented 8 years ago

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 commented 8 years ago

Lots of related ARM ABI discussion happening in https://github.com/doublethinkco/webthree-umbrella-cross/issues/21.

anthony-cros commented 8 years ago

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 commented 8 years ago

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

anthony-cros commented 8 years ago

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 commented 8 years ago

Hopefully its as simple as CT_ARCH_FLOAT_SW=n

anthony-cros commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

worth giving it a shot :)

phonikg commented 8 years ago

This is the ct-ng cli gui(oxymoron) pic that shows it as well:

http://www.crosstool-ng.org/_detail/snapshots/002-ctng-target-menu.png?id=start

anthony-cros commented 8 years ago

thanks, i played with it a bit but then realized I could simply clone an existing sample and edit the config file directly, it then gets picked up (i'll detail all the steps in a script soon)

bobsummerwill commented 8 years ago

If you guys look in #21 you will see ELF header snapshots for multiple scenarios. Looks like we should fix the NAME tag too, if we can.

bobsummerwill commented 8 years ago

Let's bump up to armv7 at the same time. That screws Rpi, but we can come back to that later.

anthony-cros commented 8 years ago

crosstool-ng's _CT_ARCHARCH seems to hold values like "armv7-a", "armv5te", so I suspect it might address the readelf _Tag_CPUarch value, but for _Tag_CPUname I'm uncertain (there is a _CT_ARCHCPU, but it has values like "arm926ej-s" and "cortex-m3")

anthony-cros commented 8 years ago

maybe _CT_ARCHARCH takes care of both _Tag_CPUarch and _Tag_CPUname

anthony-cros commented 8 years ago

starting ct-ng build with the following changes:

$ diff ~/crosstool-ng-1.20.0/install/lib/ct-ng.1.20.0/samples/arm-unknown-linux-gnueabi/crosstool.config  ~/crosstool-ng-1.20.0/install/lib/ct-ng.1.20.0/samples/arm-unknown-linux-gnueabiel/crosstool.config
5c5
< CT_ARCH_FLOAT_SW=y
---
> CT_ARCH_FLOAT_SW=n
6a7
> CT_ARCH_ARCH=armv7-a
martinbrook commented 8 years ago

http://randomsplat.com/id192-building-a-hard-float-arm-toolchain.html mentions

CT_ARCH_FPU=”vfpv3″ CT_TARGET_CFLAGS=”-mfloat-abi=hard -mfpu=vfpv3″

phonikg commented 8 years ago

Make sure we note that this link references version 1.13 and we are using 1.20

phonikg commented 8 years ago

We could always download and run the gui, then reference the configuration file it produces.

anthony-cros commented 8 years ago

@phonikg , are you talking about the ncurse GUI?

phonikg commented 8 years ago

Hmm no the crosstool-ng gui ...or are we beyond that already?

bobsummerwill commented 8 years ago

Again, back in #21 I added links to the other hacky looking bits in the build process which might need touching.

anthony-cros commented 8 years ago

i can confirm that the menu has changed since this page was written, there is now an explicit option to set hard versus float

my concern is that _CT_ARCH32=y gets removed upon switching from soft to hard, I don't know if it'll have an impact. warning says:

.config:152:warning: override: reassigning to symbol ARCH_32
.config:152:warning: override: ARCH_32 changes choice state

and I can see it being gone in crosstool-ng-1.20.0/build/.config

bobsummerwill commented 8 years ago

Right - well I guess we just need to turn the handle and see what comes out, eh!

We can compare with the metadata which @martinbrook dug out in #21 when we have new binaries.

phonikg commented 8 years ago

I can confirm that all my SBC's are 32 bit

anthony-cros commented 8 years ago

this is what I'm getting with the configuration I mentioned above:

xcompiler@d6bab4779159:~/webthree-umbrella/cross-build/ethereum$ readelf -A /home/xcompiler/eth/151116201928/installs/curl/bin/curl
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "ARM10TDMI"
  Tag_CPU_arch: v5T
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_VFP_args: VFP registers
  Tag_DIV_use: Not allowed

a little bit closer it seems... I will try to hardcode the v7 bit in the config file directly

bobsummerwill commented 8 years ago

Please could you upload the tgz for that run? Maybe I can get them running on something? Maybe @phonikg could! Thanks!

phonikg commented 8 years ago

Yes I could try it right away if you have something.

bobsummerwill commented 8 years ago

Ld.so might behave differently on different platforms. We still don't know how 'compatible binaries' for SO files are determined. Seems some bad combinations just get 'let through' and crash at runtime!

anthony-cros commented 8 years ago

the result with the hardcoding bit:

xcompiler@d6bab4779159:~/webthree-umbrella/cross-build/ethereum$ readelf -A /home/xcompiler/eth/151116201928/installs/curl/bin/curl
Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6
  Tag_DIV_use: Not allowed

name and arch now match what @martinbrook reported in https://github.com/doublethinkco/webthree-umbrella-cross/issues/21#issuecomment-159433968

anthony-cros commented 8 years ago

i only have a curl binary, I just went for the smallest bit among our components, but I'm now kicking off a full run and will send the result to you guys when it's done (tomorrow morning EST)!

bobsummerwill commented 8 years ago

Great! Thanks, @anthony-cros. Where will your commits land? Split across umbrella and umbrella-cross?

anthony-cros commented 8 years ago

:(

[ 52%] Building CXX object src/jsonrpccpp/CMakeFiles/jsonrpccommon.dir/common/specificationparser.cpp.o
cd /home/xcompiler/eth/151127041039/wd/libjson-rpc-cpp/src/jsonrpccpp && /home/xcompiler/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-g++   -Djsonrpccommon_EXPORTS -std=c++11 -isystem/home/xcompiler/eth/151127041039/installs/curl/include -fPIC -I/home/xcompiler/eth/151127041039/wd/libjson-rpc-cpp/catch/src/catch/include -I/home/xcompiler/eth/151127041039/wd/libjson-rpc-cpp/gen -I/home/xcompiler/eth/151127041039/wd/libjson-rpc-cpp/gen/jsonrpccpp/common -I/home/xcompiler/eth/151127041039/src/libjson-rpc-cpp/src/jsonrpccpp/.. -I/home/xcompiler/eth/151127041039/installs/jsoncpp/include -I/home/xcompiler/eth/151127041039/installs/libmicrohttpd/include    -o CMakeFiles/jsonrpccommon.dir/common/specificationparser.cpp.o -c /home/xcompiler/eth/151127041039/src/libjson-rpc-cpp/src/jsonrpccpp/common/specificationparser.cpp
Linking CXX shared library ../../lib/libjsonrpccpp-common.so
cd /home/xcompiler/eth/151127041039/wd/libjson-rpc-cpp/src/jsonrpccpp && /usr/bin/cmake -E cmake_link_script CMakeFiles/jsonrpccommon.dir/link.txt --verbose=1
/home/xcompiler/x-tools/arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-g++  -fPIC    -shared -Wl,-soname,libjsonrpccpp-common.so.0 -o ../../lib/libjsonrpccpp-common.so.0.6.0 CMakeFiles/jsonrpccommon.dir/common/errors.cpp.o CMakeFiles/jsonrpccommon.dir/common/specificationwriter.cpp.o CMakeFiles/jsonrpccommon.dir/common/procedure.cpp.o CMakeFiles/jsonrpccommon.dir/common/exception.cpp.o CMakeFiles/jsonrpccommon.dir/common/specificationparser.cpp.o /home/xcompiler/eth/151127041039/installs/jsoncpp/lib/libjsoncpp.a 
/home/xcompiler/x-tools/arm-unknown-linux-gnueabi/lib/gcc/arm-unknown-linux-gnueabi/4.9.1/../../../../arm-unknown-linux-gnueabi/bin/ld.bfd: /home/xcompiler/eth/151127041039/installs/jsoncpp/lib/libjsoncpp.a(json_reader.cpp.o): relocation R_ARM_MOVW_ABS_NC against `__pthread_key_create' can not be used when making a shared object; recompile with -fPIC
/home/xcompiler/eth/151127041039/installs/jsoncpp/lib/libjsoncpp.a: could not read symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [lib/libjsonrpccpp-common.so.0.6.0] Error 1
make[2]: Leaving directory `/home/xcompiler/eth/151127041039/wd/libjson-rpc-cpp'
make[1]: *** [src/jsonrpccpp/CMakeFiles/jsonrpccommon.dir/all] Error 2
make[1]: Leaving directory `/home/xcompiler/eth/151127041039/wd/libjson-rpc-cpp'
make: *** [all] Error 2

EDIT: I'll re-try with -fPIC --> nevermind it's already there

anthony-cros commented 8 years ago

@bobsummerwill , well for armhf, I was hoping only in the ct-ng.sh script, but the above error tells me I'll need to tweak a few more things in the cmake-based scripts :-/

anthony-cros commented 8 years ago

https://drive.google.com/file/d/0B4ByIjYZ3FeJMjhCVHlwMndubWc/view?usp=sharing

if you guys want to try the result curl binary at least, and see if it runs properly on an armhf device

bobsummerwill commented 8 years ago

The TM1 you have is armhf. Does it work on that?

bobsummerwill commented 8 years ago

I'm still trying to get the RD-PQ flashed and recognized by SDB. No luck yet.