Instruct the linker to set the major & minor subsystem versions in the PE
header to 6 & 1 (NT 6.1 which corresponds to Windows 7). Similar to
macOS, the binary will now refuse to run on unsupported versions of
Windows.
(cherry picked from commit e8a8cff07c409c7eecd478d3df36c7ba92c59730)
This has been around since the introduction of autotools. However at
this point I'm not sure we'd every want to suppress all warnings when
performing a build, and given that CXX FLAGS will have been overriden
when cross-compiling for Windows (using depends), this would rarely,
if-ever be used anyways.
From https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html:
-w
Inhibit all warning messages.
(cherry picked from commit 89fea68ffdbd97394d891177e664f896b3e7d1e6)
This flag was used when building 32-bit Windows executables, which we no-longer
do, and is not accepted by the linker for any of the hosts we currently build
for. i.e:
```bash
checking whether the linker accepts -Wl,--large-address-aware... no
```
--large-address-aware
If given, the appropriate bit in the "Characteristics" field of the COFF
header is set to indicate that this executable supports virtual addresses
greater than 2 gigabytes. This should be used in conjunction with the /3GB
or /USERVA=value megabytes switch in the "[operating systems]" section of
the BOOT .INI. Otherwise, this bit has no effect. [This option is specific
to PE targeted ports of the linker]
You can check that the appropriate bit in the COFF header of our current
Windows binaries is still be set using dumpbin. i.e:
```powershell
dumpbin /headers .\bitcoind.exe
FILE HEADER VALUES
<snip>
26 characteristics
Executable
Line numbers stripped
Application can handle large (>2GB) addresses
```
(cherry picked from commit acd644b83d789a6cdfbeda19732119534d10058e)
While cross compiling, HOST=x86_64-w64-mingw32, none of these
libs actually seem to be passed to the linker.
(cherry picked from commit 2525c096b002a89d4c561e1474800496ad8ebd7e)
Also remove all defines in many places and define it in configure stage to keep consistency.
(cherry picked from commit 1bd9ffdd44000b208d29d35451f4dc9f1ac9318f)
This fixes#5051, which is a regression caused by the dependency on the ntapi crate
(via mio, via tokio) added by #4947.
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
src/leveldb/build_detect_platform shows how upstream defines them.
These platform may not be able to fully build or run Bitcoin, but defining all
known to leveldb saves future hassle.
Now that all possible platforms are enumerated, specifying an unknown one is an
error.
- LevelDB platform was not guessed correctly (it ended up defining
`-DOS_OPENBSD59` instead of `-DOS_OPENBSD`)
- On OpenBSD there is no convenience link from `python3.5` to `python3`:
add detection for other python interpreter names.
- If it has to guess the LevelDB OS, print a autoconf warning so that
the user can check.
Zcash: Excludes the Python change.
Add support for FreeBSD 12
The pre-built binaries for clang 8 on FreeBSD do not ship with `libc++api`, so `libcxxrt` from the base system is used instead.
Please ensure this checklist is followed for any pull requests for this repo. This checklist must be checked by both the PR creator and by anyone who reviews the PR.
* [ ] Relevant documentation for this PR has to be completed and reviewed by @mdr0id before the PR can be merged
* [ ] A test plan for the PR must be documented in the PR notes and included in the test plan for the next regular release
As a note, all buildbot tests need to be passing and all appropriate code reviews need to be done before this PR can be merged
- Link pull-tester/rpc-tests.py to the build dir
- Add the build-dir's config to the python path so that tests can find it
- The tests themselves are in srcdir
- Clean up __pycache__ in 'make clean'
1) created rpc-tests.py
2) deleted rpc-tests.sh
3) travis.yml points to rpc-tests.py
4) Modified Makefile.am
5) Updated README.md
6) Added tests_config.py and deleted tests-config.sh
7) Modified configure.ac with script to set correct path in tests_config.py
Zcash: Migrated our test list over, and other necessary modifications.
The UI changes were not migrated.
configure.ac: Introduce macros to simplify requiring tools.
## what
Introduce two `ZC_REQUIRE_(PROG|TOOL)` macros that are like `AC_PATH_(PROG|TOOL)` except they immediately error out if the target program is not detected.
Then require almost all programs, except for two known optional cases: three programs required only if `--with-lcov` is given, and then `ccache` which has exceptional logic (The equivalent of "--enable-ccache=auto" by default, with explicit 'yes' or 'no' possible, each with different detection needs.)
## why
Provide early explicit errors for build misconfigurations. Hopefully this should never hit our "standard official flow" which relies on the `./zcutil/build.sh` path, though it may come into play for anyone experimenting with the build system or altering dependencies.
### background motivation
While prototyping a nix build system I didn't provide the `cargo` program to the `zcashd` build process. `./configure` happily exited with a success value, but the build system was instantiated with the `CARGO` make / shell variable set to the empty string, which lead to a strange command execution where a long command of `… $CARGO build …` became `… build …`, so bash looked for a program named `build`. I spent a bit too long looking for where "build" was defined in our dependencies. 😆
Update secp256k1
This migrates us to the same dependency version that upstream Bitcoin
Core migrated to in bitcoin/bitcoin#19944.
Also enables the endomorphism optimization now that the patents have
expired.
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.
Jack Grigg
Jack Grigg
Luke Dashjr
fanquake
Chun Kuan Lee
Daira Hopwood
Pieter Wuille
Igor Cota
Cory Fields
Wladimir J. van der Laan
randy-waterhouse
Homu
Marius Kjærstad
Alex Wied
Kris Nuttycombe
Dimitris Apostolou
John Newbery
Alex Morcos
ptschip
Nate Wilcox
Sean Bowe
therealyingtong
therealyingtong
Gavin Andresen
Carl Dong
practicalswift
Evan Klitzke
murrayn
Pavel Janík
Eirik Ogilvie-Wigley
Taylor Hornby