Make Rust compilation mandatory
The temporary integration check in CheckEquihashSolution() remains, until we
have "real" Rust code to integrate.
Closes#2688.
Add filename and SHA256 hash for Windows Rust package
When running `make download` in the `depends` directory, the `download-win` target (which `download` depends on) generates an error when it runs the commands defined in `check_or_remove_sources`:
```Makefile
sha256sum: /home/vagrant/zcash/depends/work/download/rust-1.16.0/..hash: no properly formatted SHA256 checksum lines found
funcs.mk:242: recipe for target '/home/vagrant/gitian-builder/cache/common/download-stamps/.stamp_fetched-rust-.hash' failed
make[1]: *** [/home/vagrant/gitian-builder/cache/common/download-stamps/.stamp_fetched-rust-.hash] Error 1
make[1]: Leaving directory '/home/vagrant/zcash/depends'
Makefile:153: recipe for target 'download-win' failed
make: *** [download-win] Error 2
```
The reason for the error is that `depends/packages/rust.mk` defines `rust_file_name_linux` and `rust_file_name_darwin` but leaves `rust_file_name_mingw32` undefined.
A directory of available rust downloads is here: https://static.rust-lang.org/dist/index.html
The closest windows analog in that list (using the same version number as currently defined in `rust.mk`) appears to be `rust-mingw-1.16.0-x86_64-pc-windows-gnu.tar.gz`. A corresponding sha256 value is also given in `rust-mingw-1.16.0-x86_64-pc-windows-gnu.tar.gz.sha256`.
After adding these values to `rust.mk`, the rust-mingw tar package was downloaded along with the rest of the dependencies and the above error message went away.
PATH variable containing spaces cause build failure
Spaces in PATH variable is creating build issues (observed on macOS). For example "VMware Fusion" adds itself to PATH like `/Applications/VMware Fusion.app/Contents/Public`.
Currently Travis's wget fails fetching qrencode:
Fetching qrencode...
ERROR: no certificate subject alternative name matches
requested host name `fukuchi.org'.
To connect to fukuchi.org insecurely, use `--no-check-certificate'.
OpenSSL: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error
Unable to establish SSL connection.
make: *** [/home/travis/build/luke-jr/bitcoin/depends/sources/download-stamps/.stamp_fetched-qrencode-qrencode-3.4.4.tar.bz2.hash] Error 4
Closes#2279. Configures CMake to enable C++11, build static libaries
and only build cpp bindings with minimal dependencies. Documentation,
examples, tests and other language bindings are no longer built.
CMake will no longer try to find commands and packages which are not
required for building the target.
Debian 8 stable ships with gcc 4.9.2 and cmake 3.0.2. Previously
the depends package used CMAKE_CXX_STANDARD to tell cmake to use
C++11, but the option requires cmakes 3.1+. To resolve the issue
we now update relevant CMakeLists.txt and set CMAKE_CXX_FLAGS.
Add a patch that seems to be necessary for compatibilty of libevent
2.0.22 with recent mingw-w64 gcc versions (at least GCC 5.3.1 from Ubuntu
16.04).
Without this patch the Content-Length in the HTTP header ends up as
`Content-Length: zu`, causing communication between the RPC
client and server to break down. See discussion in #8653.
Source: https://sourceforge.net/p/levent/bugs/363/
Thanks to @sstone for the suggestion.
V1.0.0 rc1 gitian
Removes indeterminism from gitian builds: underlying processor instruction set variant of x86_64 was being detected by the libgmp autoconf process, which caused differences in libgmp and libsnark
Upstream gitian updates
This PR pulls in all gitian-related PRs that have been merged upstream since 0.11.2. The only ones I left out were documentation-only PRs, because we removed `doc/gitian-building.md` at some point. Here are the commits applied here, in the order shown in `git log` (ie. last to first):
- bitcoin/bitcoin#7283
- fa42a67
- fa58c76
- bitcoin/bitcoin#8175
- 74c1347
- bitcoin/bitcoin#8167
- 7e7eb27
- ad38204
- b676f38
- bitcoin/bitcoin#7776
- f063863
- bitcoin/bitcoin#7424
- a81c87f ~ we already partly applied
- a8ce872
- f3d3eaf ~ we already partly applied
- 475813b
- ~~cd27bf5~~ X we already applied
- bitcoin/bitcoin#7060
- 3b468a0 ~ we removed doc/gitian-building.md
- ~~99fda26~~ X we removed doc/gitian-building.md
- bitcoin/bitcoin#7251
- fa09562
- bitcoin/bitcoin#6900
- ~~2cecb24~~ X we removed doc/gitian-building.md
- 957c0fd
- 2e31d74
- ~~0b416c6~~ X we removed QT
- 9f251b7
- bitcoin/bitcoin#6854
- 579b863 ~ we already partly applied
Part of #540
This does not break any existing prefix behavior, only makes new behavior work.
For example:
CONFIG_SITE=$PWD/depends/x86_64-pc-linux-gnu/share/config.site ./configure --prefix=/
bdb 6.X was released under the AGPL, which is incompatible with MIT-licensed
software (the result must be licensed under AGPL). bdb 5.X uses the same license
as bdb 4.8, and thus retains the same compatibility as in upstream Bitcoin.
Thanks to Luke-Jr for raising this issue.
These flags are potentially risky, because they require that the app explicitly
initialize stuff that it wouldn't otherwise need to initialize, and we don't
have time for the necessary review.
Fix inconsistent -O1/-O2, fix libzcash flags, add -fwrapv -fno-strict-aliasing
Closes#1168. In that ticket I decided the optimization flags for dependencies are out of scope, i.e. we go with whatever the upstream package maintainer chose.
Sean Bowe
Jack Grigg
Homu
Simon
Charlie O'Keefe
rofl0r
Wladimir J. van der Laan
daniel
fanquake
Cory Fields
MarcoFalke
Luke Dashjr
syd
kozyilmaz
Daira Hopwood
Jonas Schnelli
zkbot
David Mercer
Robert C. Seacord
Taylor Hornby
Nathan Wilcox