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`.
Fix buffer overflow in libsnark
Applies `-fstack-protector-all` to libsnark, and fixes an underlying bug. This bug was not triggerable in `zcashd` because the function in question was being inlined by the compiler.
Closes#2788.
Build system improvements
Includes commits cherry-picked from the following upstream PRs:
- bitcoin/bitcoin#6978
- Only the first commit (second is for QT)
- bitcoin/bitcoin#7059
- bitcoin/bitcoin#7603
- Only the first commit (without the `BITCOIN_QT_BIN` variable; the rest are for QT)
- bitcoin/bitcoin#7954
- bitcoin/bitcoin#8314
- Only the second commit (first is for QT)
- bitcoin/bitcoin#8504
- Only the first commit (second was undoing something we didn't have)
- bitcoin/bitcoin#8520
- bitcoin/bitcoin#8563
- bitcoin/bitcoin#8249
- bitcoin/bitcoin#9156
- bitcoin/bitcoin#9831
- bitcoin/bitcoin#9789
- bitcoin/bitcoin#10766
Part of #2074.
Delta values will be stored for new blocks; old blocks can be filled in by
re-indexing. The net value currently in the Sprout circuit is only calculated
when delta values for all previous blocks are present.
Add examples for z_rpc calls
Adds missing cli and json-rpc examples for `z_` rpc calls
Closes#2723
(Accidentally named the branch being merged in with wrong issue number)
We don't use any elliptic curves from OpenSSL anymore, nor include this
header anywhere but optionally in the tests of secp256k1 (which has
its own autoconf setup).
Reported by sinetek on IRC.
- guard PKG_PROG_PKG_CONFIG with an m4_ifdef. If not building for windows,
require it
- add nops as necessary in case the ifdef reduces the if/then to nothing
- AC_SUBST some missing _LIBS. These were split out over time, but not all were
properly substituted. They continued to work if pkg-config is installed
because it does the AC_SUBST itself
Disabling warnings can be tricky, because doing so can cause a different
compiler to create new warnings about unsupported disable flags. Also, some
warnings don't surface until they're paired with another warning (gcc). For
example, adding "-Wno-foo" won't cause any trouble, but if there's a legitimate
warning emitted, the "unknown option -Wno-foo" will show up as well.
Work around this in 2 ways:
1. When checking to see if -Wno-foo is supported, check for "-Wfoo" instead.
2. Enable -Werror while checking 1.
If "-Werror -Wfoo" compiles, "-Wno-foo" is almost guaranteed to be supported.
-Werror itself is also checked. If that fails to compile by itself, it likely
means that the user added a flag that adds a warning. In that case, -Werror
won't be used while checking, and the build may be extra noisy. The user would
need to fix the bad input flag.
Also, silence 2 more additional warnings that can show up post-c++11.
Unfortunately, the target namees defined at the Makefile.am level can't be used
for *.in substitution. So these new defines will have to stay synced up with
those targets.
Using the new variables for the deploy targets in the main Makefile.am will
ensure that they stay in sync, otherwise build tests will fail.
Homu
Jack Grigg
Jay Graber
syd
Simon
René Nyffenegger
Cory Fields
Jonas Schnelli
Wladimir J. van der Laan
Anthony Towns
daniel
fanquake