zcash/zcash#4740 removed OpenSSL from our depends system, so we were
not satisfying this linker flag intentionally. Configurations where a
target OpenSSL could not be found by the linker, such as cross-compiles
and native macOS builds, were therefore failing. However, OpenSSL is
likely available in the system for all the "supported builders" (which
are all Linux-based), so the linker was likely being satisfied by that
library, enabling the previous PR to be merged.
leveldb's buildsystem causes us a few problems:
- breaks out-of-tree builds
- forces flags used for some tools
- limits cross builds
Rather than continuing to add wrappers around it, simply integrate it into our
build.
The --enable-online-rust configure flag replicates the behaviour of the
LIBRUSTZCASH_OVERRIDE environment variable (enabling the build system to
use crates.io instead of vendored dependencies).
-fwrapv and -ftrapv conflict, and whichever is last takes precedence
(for gcc). This meant that -ftrapv was being ignored when --enable-debug
was set. This commit correctly sets only one of them based on whether
--enable-debug is set.
Part of #4317.
Benchmarking framework, loosely based on google's micro-benchmarking
library (https://github.com/google/benchmark)
Wny not use the Google Benchmark framework? Because adding Even More Dependencies
isn't worth it. If we get a dozen or three benchmarks and need nanosecond-accurate
timings of threaded code then switching to the full-blown Google Benchmark library
should be considered.
The benchmark framework is hard-coded to run each benchmark for one wall-clock second,
and then spits out .csv-format timing information to stdout. It is left as an
exercise for later (or maybe never) to add command-line arguments to specify which
benchmark(s) to run, how long to run them for, how to format results, etc etc etc.
Again, see the Google Benchmark framework for where that might end up.
See src/bench/MilliSleep.cpp for a sanity-test benchmark that just benchmarks
'sleep 100 milliseconds.'
To compile and run benchmarks:
cd src; make bench
Sample output:
Benchmark,count,min,max,average
Sleep100ms,10,0.101854,0.105059,0.103881
Various changes:
* Don't check $GCC and $GXX
* Prefer -Og instead of -O0
* If -g3 isn't available, use -g
This also incidentally fixes compiler warnings with GCC and glibc when using
--enable-debug, as the old default values mixed poorly with the hardening flags.
Add AFL in zcutil (with all-in-one script)
Supersedes #4156 and #4167.
Fuzzing targets and input sets are defined by the contents of directories in `./src/fuzzing/`. Inside the directory, there's a `fuzz.cpp` and `fuzz.h` with a `main()` function that will replace `zcashd`'s actual `main()` as well as an `input` subdirectory containing the inputs, one per file. To just run a fuzzer, you can, for example...
```
make clean # if you've previously build zcashd without AFL instrumentation
./zcutil/afl/afl-getbuildrun.sh DecodeHexTx
```
Alternatively you can...
```
./zcutil/afl/afl-get.sh /tmp/afl # (or wherever you want to build AFL)
./zcutil/afl/afl-build.sh /tmp/afl DecodeHexTx -j$(nproc)
./zcutil/afl/afl-run.sh /tmp/afl DecodeHexTx
```
Run `make clean` whenever you switch between a normal build and an AFL-instrumented build.
depends: Support additional cross-compilation targets in Rust
This will make it easier for third parties to cross-compile `zcashd` for other platforms. The third commit in this PR shows how to add a new target to the Rust dependency builder.
The default Rust target during cross-compilation is the canonical host, which is derived from `HOST` using `depends/config.sub`. If the canonical host differs from the required Rust target, add the necessary mapping in addition to the target itself.
Also includes fixes for cross-compiling aarch64 targets.
Disable building libzcashconsensus by default
The library is not currently a supported build artifact; it needs work in
order to build on certain platforms (e.g. MacOS), and its dependencies need to
be narrowed down (Equihash is not a requirement for validating scripts).
The library is not currently a supported build artifact; it needs work in
order to build on certain platforms (e.g. MacOS), and its dependencies need to
be narrowed down (Equihash is not a requirement for validating scripts).