If you’re compiling natively on the device, you should not need the HOST parameter. Where does it fail when you just compile with ./zcutil/build.sh?
Yes, it was updated. I was mainly trying to remove the extra step of having to compile on another PC to transfer to the Smartphone.
1 Like
Hello.
I’m trying to x-compile using the instructions from by @garethtdavies from here (using the “Docker solution”). However, I’m bumping into the following errors:
CXXLD zcashd
ld.lld: error: libbitcoin_server.a(libbitcoin_server_a-asyncrpcqueue.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_server.a(libbitcoin_server_a-asyncrpcoperation.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_common.a(libbitcoin_common_a-bech32.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_common.a(libbitcoin_common_a-scheduler.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_common.a(libbitcoin_common_a-script_error.o) is incompatible with aarch64linux
ld.lld: error: univalue/.libs/libunivalue.a(libunivalue_la-univalue.o) is incompatible with aarch64linux
ld.lld: error: univalue/.libs/libunivalue.a(libunivalue_la-univalue_get.o) is incompatible with aarch64linux
ld.lld: error: univalue/.libs/libunivalue.a(libunivalue_la-univalue_read.o) is incompatible with aarch64linux
ld.lld: error: univalue/.libs/libunivalue.a(libunivalue_la-univalue_write.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_util.a(libbitcoin_util_a-glibcxx_sanity.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_util.a(libbitcoin_util_a-fs.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_util.a(libbitcoin_util_a-cleanse.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_util.a(libbitcoin_util_a-uint256.o) is incompatible with aarch64linux
ld.lld: error: libbitcoin_util.a(libbitcoin_util_a-utilstrencodings.o) is incompatible with aarch64linux
ld.lld: error: libzcash.a(libzcash_a-util.o) is incompatible with aarch64linux
ld.lld: error: leveldb/libleveldb.a(libleveldb_a-db_impl.o) is incompatible with aarch64linux
ld.lld: error: leveldb/libleveldb.a(libleveldb_a-write_batch.o) is incompatible with aarch64linux
ld.lld: error: leveldb/libleveldb.a(libleveldb_a-bloom.o) is incompatible with aarch64linux
ld.lld: error: leveldb/libleveldb.a(libleveldb_a-cache.o) is incompatible with aarch64linux
ld.lld: error: leveldb/libleveldb.a(libleveldb_a-env_posix.o) is incompatible with aarch64linux
ld.lld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
clang-8: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [Makefile:3321: zcashd] Error 1
make[2]: Leaving directory '/zcash/src'
make[1]: *** [Makefile:7800: all-recursive] Error 1
make[1]: Leaving directory '/zcash/src'
make: *** [Makefile:634: all-recursive] Error 1
I’d appreciate it so much if anyone could guide me a bit on how to overcome these 
(btw… seems like fetch-params.sh and zcash-cli have compiled just fine).
Actually… Never mind! I think it must have been something I messed-up in the process: I started off again from scratch and it worked perfectly! 
1 Like
Nice, what are you running it on?
I’m trying the RPi 4 with 4GB. Left it running for a while now but it’s suddenly got really slow 
It’s probably crunching through some full blocks around the 300k to 400k blockheight. All nodes do this, just let it run and it will get through it.
1 Like
FWIW, depending on the SBC you might need to modify swap space for a successful mainnet sync.
Interesting… How so? I would like to do that. Currently it’s at something like ~250k blocks.
Is it just me, or this site doesn’t offer downloads of the builds it tests?
If the latter, could you please publish the arm64 builds in some form? There hasn’t been progress on this front for a long time and even just releasing them as “unofficial” builds would make adoption easier (versus everyone building for themselves).
It turns out I misunderstood that builder at the time I made that post; it is actually testing the cross-compile. There’s an issue open for native ARM64 support.
This is indeed something we are working towards. It’s been hampered by limitations both in our CI and in the deterministic build system we use for releases, but both of those are in the process of being addressed. What I’d like to eventually have is “tiers” of support (similar to the Rust compiler), where the current binaries we provide are equivalent to Tier 1.
3 Likes
Cross-compile as in using e.g. an x64_86 platform to create aarch64 builds? If that’s the case, again, can I ask you to please publish the builds, even if you need to label them as unofficial and experimental? The way I interpret your CI is that the cross-compiled builds it tests seem to work on aarch64. Is my understanding incorrect, or is there something else that is a blocker to doing this?
1 Like
The cross-compiled builds are indeed what we would publish, after the aforementioned CI and build system limitations are addressed.
2 Likes
To Str4d’s point above we aren’t quite there yet, but if you do need an untested/unsupported ARM binary to experiment with from fairly recent on master:
ipfs get /ipfs/QmWEadk44oqz84HJ5LumohBvEeMvAwFQMMtm8G8aLEaxA6 -o zcashd-artifacts-aarch64-linux-gnu-90232f6.tgz
Built from GIT_COMMIT=90232f6. More to come soon 
1 Like
thanks a great lot @mdr0id, I really appreciate it! but for that hash I get Error: merkledag: not found. other hashes work for me. could you check if it’s still in the IPFS network?
@slush No worries. Always happy to help as much as possible. I verified the CID is valid still.
Please ensure your ipfs daemon is installed and running:
ipfs daemon &
Then run the prior command:
ipfs get /ipfs/QmWEadk44oqz84HJ5LumohBvEeMvAwFQMMtm8G8aLEaxA6 -o zcashd-artifacts-aarch64-linux-gnu-90232f6.tgz
You likely will notice logs while downloading binaries, but these are expected:
15:31:41.319 ERROR basichost: setting stream deadline: stream closed basic_host.go:238
15:32:46.417 ERROR basichost: setting stream deadline: stream closed basic_host.go:238
15:38:29.012 ERROR basichost: setting stream deadline: stream closed basic_host.go:238
15:40:25.309 ERROR basichost: setting stream deadline: stream closed basic_host.go:238
15:41:08.678 ERROR basichost: setting stream deadline: stream closed basic_host.go:238
15:41:08.678 ERROR basichost: setting stream deadline: stream closed basic_host.go:238
Once complete, you should have zcashd-artifacts-aarch64-linux-gnu-90232f6.tgz.
The last remaining item to get the node running on ARM is the params:
ipfs get /ipfs/QmUSFo5zgPPXXejidzFWZcxVyF3AJH6Pr9br6Xisdww1r1 -o zcash-params.tgz
It might take a while to download these files depending on your ISP/GeoLoc/IPFS peer count. If IPFS doesn’t work to get the parameters, you can always use the standard ‘fetch-params.sh’ in zcash repo.
1 Like
many thanks @mdr0id. I began using ipfs only recently so I’m sure I made mistakes, but I couldn’t get the build to download on my own ipfs CLI client. it’s as if the daemon froze when I requested this specific content. also tried from ipfs-desktop, and it kept searching indefinitely. but I managed to get the content through a hosted gateway. I’m clueless.
on a positive note, the build works, and apart from some issues, it’s absolutely usable! I’m thankful you built it and shared it with the world. I’ll leave some notes below about the issues in case that helps stabilizing the build.
- importing private keys with the rescan argument consistently caused zcashd to become unresponsive, and after ~5 minutes, crash on its own. when I launched it again, it did the rescan, so I eventually got what I wanted, just with hiccups and taking more time. when this after-the crash rescan happened, z-addresses were rescanned from block 0, so that consumed a lot of time. but nothing was damaged. if it matters, all these happened on (unlocked) password-protected wallet.dat’s.
- it crashed once without any reason, after which the block index became corrupted and the data needed a reindexing. that took an awful lot of time, on the order of intial block download and verification. I wonder if it also re-verified the PoW and that is what took so long.
- there have been a few graphical glitches, zcashd stats lines multiplying and such, especially when I moved around the terminal window a lot, or there was something else computationally intensive happening.
2 Likes