glibc 2.33 introduced a new fortification level, _FORTIFY_SOURCE=3.
Which improves the coverage of cases where _FORTIFY_SOURCE can use _chk
functions. For example, using GCC 13 and glibc 2.36 (Fedora Rawhide),
compiling master:
```bash
nm -C src/bitcoind | grep _chk
U __fprintf_chk@GLIBC_2.17
U __memcpy_chk@GLIBC_2.17
U __snprintf_chk@GLIBC_2.17
U __sprintf_chk@GLIBC_2.17
U __stack_chk_fail@GLIBC_2.17
U __stack_chk_guard@GLIBC_2.17
U __vsnprintf_chk@GLIBC_2.17
objdump -d src/bitcoind | grep "_chk@plt" | wc -l
33
```
vs this branch:
```bash
nm -C src/bitcoind | grep _chk
U __fprintf_chk@GLIBC_2.17
U __memcpy_chk@GLIBC_2.17
U __memset_chk@GLIBC_2.17
U __snprintf_chk@GLIBC_2.17
U __sprintf_chk@GLIBC_2.17
U __stack_chk_fail@GLIBC_2.17
U __stack_chk_guard@GLIBC_2.17
U __vsnprintf_chk@GLIBC_2.17
objdump -d src/bitcoind | grep "_chk@plt" | wc -l
61
```
Usage of level 3 requires LLVM/Clang 9+, or GCC 12+. Older
compilers/glibc will still use _FORTIFY_SOURCE=2. For example, in the
glibc we currently use for Linux release builds (2.24), FORTIFY_LEVEL is
determined using the following:
```c
```
so any value > 1 will turn on _FORTIFY_SOURCE=2.
https://sourceware.org/pipermail/libc-alpha/2021-February/122207.htmlhttps://developers.redhat.com/blog/2021/04/16/broadening-compiler-checks-for-buffer-overflows-in-_fortify_source
Even though all other targets are disabled, we still need Boost CPPFLAGS
(use_boost) to compile. This currently works everywhere, except on arm
macOS (where the include path is pretty non-standard), because
generally, the Boost include path is generic, i.e `/usr/include`.
d4c59da8d6 build: Avoid `BOOST_NO_CXX98_FUNCTION_BASE` macro redefinition (Hennadii Stepanov)
Pull request description:
With GCC 12 and Boost 1.81 (from depends) having multiple warnings:
```
In file included from /home/hebasto/bitcoin/depends/x86_64-pc-linux-gnu/include/boost/config.hpp:48:
/home/hebasto/bitcoin/depends/x86_64-pc-linux-gnu/include/boost/config/stdlib/libstdcpp3.hpp:397:9: warning: 'BOOST_NO_CXX98_FUNCTION_BASE' macro redefined [-Wmacro-redefined]
#define BOOST_NO_CXX98_FUNCTION_BASE
^
<command line>:8:9: note: previous definition is here
#define BOOST_NO_CXX98_FUNCTION_BASE 1
^
1 warning generated.
```
This PR fixes those warnings.
Defining of the `BOOST_NO_CXX98_FUNCTION_BASE` macro was introduced in https://github.com/bitcoin/bitcoin/pull/25436, but since https://github.com/boostorg/config/pull/430, it is required to check it before adding.
ACKs for top commit:
fanquake:
ACK d4c59da8d6 - it works now.
Tree-SHA512: 53b9ddcf8dad729638ed41251e30c80f2d7d1ae3ffe47466865834f1f10184fe0881abeb339b3e46c270c3eb11fb63d19ab12cc9461bf5c2be12b4763c1b1c34
d51f0fa4b7 doc: add release notes for 26896 (fanquake)
2b248798d9 build: remove --enable-upnp-default from configure (fanquake)
02f5a5e7b5 build: remove --enable-natpmp-default from configure (fanquake)
25a0e8ba0b Remove configure-time setting of DEFAULT_UPNP (fanquake)
06562e5fa7 Remove configure-time setting of DEFAULT_NATPMP (fanquake)
Pull request description:
This PR removes the `--enable-upnp-default` and `--enable-natpmp-default` options from configure.
It's odd to me that we maintain configure-time options for setting the default port-forwarding runtime state (but no other similar options), and I'm not sure what use-case it satisfies, that can't be achieved by multiple other means. I also doubt that we'll ever restart using these in release builds, or turning on any of this by default.
I think the only scenario these options would be used is when you want to compile your own binaries (we don't use them in Guix), with port-forwarding on by default, but otherwise can't or don't want to use a `.conf` file, can't or don't want to pass command line options at runtime, and also don't want to modify the source code?
ACKs for top commit:
hebasto:
ACK d51f0fa4b7, rebased and comments have been addressed since my recent [review](https://github.com/bitcoin/bitcoin/pull/26896#pullrequestreview-1273910740).
TheCharlatan:
ACK d51f0fa4b7
Tree-SHA512: 481decd8bddd8b03b7319591e3acf189f7b6b96c9a9a8c5bc1a3f8ec00d0b8f9b52d2f5c28a298a2ec947cfe9611cfd184e393ccb2e4e21bfce86ca7d4de60d3
0f883df7a5 build: fix configuring with only bitcoin-util (fanquake)
Pull request description:
Fixes the issue presented in #25037 in a single (easily backportable) diff, with no additional refactoring/changes.
Can be tested with:
```bash
./configure \
--disable-tests \
--disable-bench \
--without-libs \
--without-daemon \
--without-gui \
--disable-fuzz-binary \
--without-utils \
--enable-util-util
```
ACKs for top commit:
TheCharlatan:
tACK 0f883df7a5
hebasto:
ACK 0f883df7a5, tested on Ubuntu 22.04.
Tree-SHA512: 3682712405c360852c4edd90c171e21302154bf8789252c64083974a5c873cf04d97e8721c7916d5b2dafa6acd2b8dc32deecf550e90e03bcbbabbbbf75ce959
2022917223 Add secp256k1_selftest call (Pieter Wuille)
3bfca788b0 Remove explicit enabling of default modules (Pieter Wuille)
4462cb0498 Adapt to libsecp256k1 API changes (Pieter Wuille)
9d47e7b71b Squashed 'src/secp256k1/' changes from 44c2452fd3..21ffe4b22a (Pieter Wuille)
Pull request description:
Now that libsecp256k1 has a release (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021271.html), update the subtree to match it.
The changes themselves are not very impactful for Bitcoin Core, but include:
* It's no longer needed to specify whether contexts are for signing or verification or both (all contexts support everything), so make use of that in this PR.
* Verification operations can use the static context now, removing the need for some infrastructure in pubkey.cpp to make sure a context exists.
* Most modules are now enabled by default, so we can drop explicit enabling for them.
* CI improvements (in particular, MSVC and more recent MacOS)
* Introduction of an internal int128 type, which has no effect for GCC/Clang builds, but enables 128-bit multiplication in MSVC, giving a ~20% speedup there (but still slower than GCC/Clang).
* Release process changes (process documentation, changelog, ...).
ACKs for top commit:
Sjors:
ACK 2022917223, but 4462cb0498 could use more eyes on it.
achow101:
ACK 2022917223
jonasnick:
utACK 2022917223
Tree-SHA512: 8a9fe28852abe74abd6f96fef16a94d5a427b1d99bff4caab1699014d24698aab9b966a5364a46ed1001c07a7c1d825154ed4e6557c7decce952b77330a8616b
Fixes the issue presented in #25037 in a single (easily backportable)
diff, with no additional refactoring/changes.
Can be tested with:
```bash
./configure \
--disable-tests \
--disable-bench \
--without-libs \
--without-daemon \
--without-gui \
--disable-fuzz-binary \
--without-utils \
--enable-util-util
```
These headers are already included in a default set which are checked
early during configure.
We already use at least sys/types.h and unistd.h unconditionally in
configure.
98868633d1 Bugfix: configure: bitcoin-{cli,tx,util} don't need UPnP, NAT-PMP, or ZMQ (Luke Dashjr)
Pull request description:
As with #23345, these other tools likewise don't use various deps.
ACKs for top commit:
achow101:
ACK 98868633d1
Tree-SHA512: 4be056b8e0c9f69834229aa257187457de1bc34214d320b770834e21ecc1f0ca7aa7b9689fba525928947bfabbb461528795f709014fb9618b82f088fe64f271
d216d714aa Revert "build: Use Homebrew's sqlite package if it is available" (fanquake)
Pull request description:
This reverts ee7b84e63c from #20527.
That change was made without any rationale, maybe other than, a brew
installed version might be newer, and that's "better". However when
building from source on macOS, it just results in drastically worse
performance, and issues / confusion like #25724.
The difference in performance can be observed using the example from https://github.com/bitcoin/bitcoin/issues/25724#issuecomment-1213554922,
but minified i.e:
```bash
time src/bitcoin-cli createwallet speedy true
time src/bitcoin-cli importdescriptors '[
{"desc":"raw(00145846369f3d6ba366d6f5a903fb5cf4dca3763c0e)#k9wh6v62","timestamp":"now"},
{"desc":"raw(001420800aabf13f3a4c4ce3ce4c66cecf1d17f21a6e)#6m0hlfh4","timestamp":"now"},
{"desc":"raw(0014c6bf9715e06d73ebf9b3b02d5cc48d24d8bbabc1)#wyavh36r","timestamp":"now"},
{"desc":"raw(00141ba7807b3f46af113beaea5c698428ce7138cd8a)#jctdsups","timestamp":"now"},
{"desc":"raw(00140c1bd27f10fff01b36ddf3c1febaa1acff19b080)#9s6nc3pk","timestamp":"now"},
{"desc":"raw(00141226e31987e4bc2e63c0ee12908f675e40464b20)#9pp7qm39","timestamp":"now"},
{"desc":"raw(0014f73f149f7503960a5e849c6ee7a8a8c336f631cb)#qtkxv9fc","timestamp":"now"},
{"desc":"raw(0014c8ccb4d81ffc769fc5fdd8d7eed69b0e0cae5749)#hn39qayv","timestamp":"now"},
{"desc":"raw(001498565aead2d67a22a6021d55210f2a917fc22169)#6ar3vwsx","timestamp":"now"},
{"desc":"raw(001403013248ac0cd9eabe176cad162cda2a19f771e1)#4m47mukd","timestamp":"now"}
]'
```
Running master, when building from souce and using brew installed
sqlite, this takes ~3.4s. With this PR, the same operation takes ~0.3s.
Resolves the "build from source" portion of #25724. Building from
depends is still not ideal, however I have some other changes that might
help improve things in that case.
Related performance issue reports:
* https://github.com/bitcoindevkit/bdk/issues/749
* https://bitcoin.stackexchange.com/questions/113898/bitcoin-v23-is-10-times-slower-than-v22-on-macos-for-basic-regtest-tests
* https://github.com/bitcoin/bitcoin/issues/25724
* https://github.com/bitcoin/bitcoin/pull/25985#issuecomment-1245942400
ACKs for top commit:
achow101:
ACK d216d714aa
jarolrod:
ACK d216d714aa
hebasto:
ACK d216d714aa, I have reviewed the code and it looks OK, I agree it can be merged. No conflicts with our build [docs](d216d714aa/doc/build-osx.md (descriptor-wallet-support)).
Tree-SHA512: 1bb4b44385b11fa9fe66edd7449278f9e47a6cc679b7111f9adf17db94c34e29c9cceafc917454e134420db40b24b56da29226af6f43e6dbeff822b79b77ed60
We currently perform the same check twice, to put the same set of flags
in two different variables. Split the checks so we test for crc and crypto
extensions independently.
If we don't want to split, we should just delete the second AX_CHECK_COMPILE_FLAG
check, and set ARM_CRC_CXXFLAGS & ARM_CRC_CXXFLAGS at the same time.
We already use a mix of <cstdlib> and stdlib.h unconditionally throughout
the codebase.
Us checking this header also duplicates work already done by autotools.
Currently stdlib.h is checked for 3 times during a ./configure run, after
this change, at least it's only twice.
We already use a mix of <cstdio> and stdio.h unconditionally throughout
the codebase.
Us checking this header also duplicates work already done by autotools.
Currently stdio.h is checked for 3 times during a ./configure run, after
this change, at least it's only twice.
We don't include strings.h anywhere.
This is also already checked for by autoconf, so us checking for it just
means a 3rd existence check during ./configure.
This reverts ee7b84e63c from #20527.
This change was made without any rationale, maybe other than a brew
installed version might be newer, and that's "better". However when
building from source on macOS, it just results in drastically worse
perofrmance, and results in issues / confusions like #25724.
Resolves the "build from source" portion of #25724. Building from
depends is still not ideal, however I have some other changes that might
help improve things in that case.
The difference in performance can be observed using the example from
https://github.com/bitcoin/bitcoin/issues/25724#issuecomment-1213554922,
but minified to only 10 descriptors. i.e:
```bash
time src/bitcoin-cli createwallet speedy true
time src/bitcoin-cli importdescriptors '[
{"desc":"raw(00145846369f3d6ba366d6f5a903fb5cf4dca3763c0e)#k9wh6v62","timestamp":"now"},
{"desc":"raw(001420800aabf13f3a4c4ce3ce4c66cecf1d17f21a6e)#6m0hlfh4","timestamp":"now"},
{"desc":"raw(0014c6bf9715e06d73ebf9b3b02d5cc48d24d8bbabc1)#wyavh36r","timestamp":"now"},
{"desc":"raw(00141ba7807b3f46af113beaea5c698428ce7138cd8a)#jctdsups","timestamp":"now"},
{"desc":"raw(00140c1bd27f10fff01b36ddf3c1febaa1acff19b080)#9s6nc3pk","timestamp":"now"},
{"desc":"raw(00141226e31987e4bc2e63c0ee12908f675e40464b20)#9pp7qm39","timestamp":"now"},
{"desc":"raw(0014f73f149f7503960a5e849c6ee7a8a8c336f631cb)#qtkxv9fc","timestamp":"now"},
{"desc":"raw(0014c8ccb4d81ffc769fc5fdd8d7eed69b0e0cae5749)#hn39qayv","timestamp":"now"},
{"desc":"raw(001498565aead2d67a22a6021d55210f2a917fc22169)#6ar3vwsx","timestamp":"now"},
{"desc":"raw(001403013248ac0cd9eabe176cad162cda2a19f771e1)#4m47mukd","timestamp":"now"}
]'
```
Running master, when building from souce and using brew installed
sqlite, this takes ~3.4s. With this PR, the same operation takes ~0.3s.
8df063e537 build: Fix help string for `--enable-external-signer` configure option (Hennadii Stepanov)
Pull request description:
This PR is a follow up of bitcoin/bitcoin#24065 and fixes the help string according to the actual default value 816ca01650/configure.ac (L324-L327)
ACKs for top commit:
kristapsk:
cr utACK 8df063e537
jarolrod:
ACK 8df063e537
Tree-SHA512: ad3f457a53c9238ddd8ded9efd1224e564e6cb9da8b7ff7733a11e32a7daad5c0f6c6223509218f44944a874470cb0d2447897662eaf4e78c763b30785717c50
9aeeb75cf9 Add symlinks for hardcoded Makefiles in out of tree builds (Pablo Greco)
Pull request description:
When doing out of tree builds, some hardwired Makefiles are not symlinked, which makes it a bit more uncomfortable to run some instances of make.
There's no "real" functionality loss without this patch because the symlinked files are just for quick access to thinks in the main Makefile
ACKs for top commit:
hebasto:
ACK 9aeeb75cf9, tested on Ubuntu 22.04.
Tree-SHA512: 656f73c387584cee34f66b3f95993267a40b915762949c7a84b73ba2ea8d37b7b5850733377110e0110ed2f7da64e6a5f9b303812080fe7815154dbb40c8a44c
Our usage of std::atomic is with it's own exchange function, not
std::atomic_exchange. So we should be looking specifically for that
function.
Additionally, -pthread and -lpthread have an effect on whether -latomic
will be needed, so the atomics check needs to use these flags as well.
This will make the flags in use better match what is actually used when
linking.
This removes the need for -latomic for riscv builds, which resolves a
guix cross architecture reproducibility issue.
Boost conatiner_hash (included via functional -> multi_index) uses
std::unary_function, which was deprecated in C++11, and "removed" in
C++17. It's use causes wanrings with newer compilers, i.e GCC 12.1.
```bash
/bitcoin/depends/aarch64-unknown-linux-gnu/include/boost/container_hash/hash.hpp:131:33:
warning: 'template<class _Arg, class _Result> struct std::unary_function' is deprecated [-Wdeprecated-declarations]
131 | struct hash_base : std::unary_function<T, std::size_t> {};
| ^~~~~~~~~~~~~~
In file included from /usr/include/c++/12/bits/unique_ptr.h:37,
from /usr/include/c++/12/memory:76,
from ./init.h:10,
from init.cpp:10:
/usr/include/c++/12/bits/stl_function.h:117:12: note: declared here
117 | struct unary_function
```
Use the MACRO outlined in
https://github.com/boostorg/container_hash/issues/22, to prevent it's
use.
BOOST_NO_CXX98_FUNCTION_BASE:
> The standard library no longer supports std::unary_function and std::binary_function.
> They were deprecated in C++11 and is removed from C++14.
See:
https://github.com/boostorg/config/pull/430https://en.cppreference.com/w/cpp/utility/functional/unary_functionhttps://www.boost.org/doc/libs/master/libs/config/doc/html/boost_config/boost_macro_reference.html
58a9601dff build: globally define NOMINMAX (fanquake)
Pull request description:
Define (and document) `NOMINMAX` once, rather than across multiple
source files.
Defining this prevents the definition of min/max macros when using
mingw-w64, which may conflict with unprefixed std::min/max usage. While
that might not be the case for us, we'd always prefer to use the standard
library in any case.
For example:
73cadc06c6/mingw-w64-headers/include/ntdef.h (L289-L300)
Note that we already define NOMINMAX globally when building with MSVC.
Guix Build (arm64):
```bash
d3a3b7045dc1677f6a0a2a73a484f156c81ae764058003d9e870b346912b744a guix-build-58a9601dffa6/output/arm-linux-gnueabihf/SHA256SUMS.part
3e66540a3f8c8a10864ab2fed69581241fa41af86bbb028e5f7c3dd4ba859c64 guix-build-58a9601dffa6/output/arm-linux-gnueabihf/bitcoin-58a9601dffa6-arm-linux-gnueabihf-debug.tar.gz
78756e20d45e327cfd7f9e65858bf6d3814bcbe08f9f825fd6dfc9dff999ea6d guix-build-58a9601dffa6/output/arm-linux-gnueabihf/bitcoin-58a9601dffa6-arm-linux-gnueabihf.tar.gz
11073e88d4fd0411c5119a3dca3a90788693fa9aa5134339c84be98ae893cd77 guix-build-58a9601dffa6/output/arm64-apple-darwin/SHA256SUMS.part
deffd5f8c6286be34bc35e71ec70300bacb37e1b1a83e67c0833cb57d7a45529 guix-build-58a9601dffa6/output/arm64-apple-darwin/bitcoin-58a9601dffa6-arm64-apple-darwin-unsigned.dmg
acee7e98c5ec41f67e86c78dc5b45fa8bc82de86a04b8c43dbf9c59e7aff36a9 guix-build-58a9601dffa6/output/arm64-apple-darwin/bitcoin-58a9601dffa6-arm64-apple-darwin-unsigned.tar.gz
83f7cbaf6680fe8981db9260b97ca87d609a76c0857a744c7d406645d2484e1b guix-build-58a9601dffa6/output/arm64-apple-darwin/bitcoin-58a9601dffa6-arm64-apple-darwin.tar.gz
b8c73b40a5e307e9e7e482ce92164990d442f3f105a5240ec6eb96a775cb35d5 guix-build-58a9601dffa6/output/dist-archive/bitcoin-58a9601dffa6.tar.gz
cc435cd925771af7e261d0121047339ea8fddb0d1548b699c12108a62988cd32 guix-build-58a9601dffa6/output/powerpc64-linux-gnu/SHA256SUMS.part
7a68bd3181a054056b0a5eb6e830b90ac4ba8435114127d5f1720643011aa78f guix-build-58a9601dffa6/output/powerpc64-linux-gnu/bitcoin-58a9601dffa6-powerpc64-linux-gnu-debug.tar.gz
bc55b95e263c455a964d9463a3ee60dabee1d10cefc6641ed29a3b1b317d61e0 guix-build-58a9601dffa6/output/powerpc64-linux-gnu/bitcoin-58a9601dffa6-powerpc64-linux-gnu.tar.gz
49df78009d80af02262806c6c395e2c884a979b1ea13d01aa27d8188403e29d1 guix-build-58a9601dffa6/output/powerpc64le-linux-gnu/SHA256SUMS.part
29dc7a0e10707b3511fa2afb6977df7ebbb67f796d8be5a042abc14eba764aef guix-build-58a9601dffa6/output/powerpc64le-linux-gnu/bitcoin-58a9601dffa6-powerpc64le-linux-gnu-debug.tar.gz
51b7f8e1bccff1e2ce1860bbc382eefe648b90cc3374cdfa3a95a7454386e77d guix-build-58a9601dffa6/output/powerpc64le-linux-gnu/bitcoin-58a9601dffa6-powerpc64le-linux-gnu.tar.gz
e62e46d8cebbbfc0f587e930acb648fcae99cfe8b2f63aeba98e46e3338fe1e3 guix-build-58a9601dffa6/output/riscv64-linux-gnu/SHA256SUMS.part
fa5d0a074ca586583bf08dbf748909b3ff5e0a54a2e5aaa88abec666e17b4e72 guix-build-58a9601dffa6/output/riscv64-linux-gnu/bitcoin-58a9601dffa6-riscv64-linux-gnu-debug.tar.gz
684b2917fd27a41f884bb6870f7fac847d52b6f8b40df5779d1c674409f7cd14 guix-build-58a9601dffa6/output/riscv64-linux-gnu/bitcoin-58a9601dffa6-riscv64-linux-gnu.tar.gz
7d7cfd0212b49eec48c7f8dc0d97add53096685dfd646feac466c27a45d20c97 guix-build-58a9601dffa6/output/x86_64-apple-darwin/SHA256SUMS.part
d70ae6d060b7832f8741dc5d1958cc0d32702605c863254303107246deec0aa6 guix-build-58a9601dffa6/output/x86_64-apple-darwin/bitcoin-58a9601dffa6-x86_64-apple-darwin-unsigned.dmg
930f3ec43896404208ebdb582c9175e3a5a2470d778722e0001addde84dad99a guix-build-58a9601dffa6/output/x86_64-apple-darwin/bitcoin-58a9601dffa6-x86_64-apple-darwin-unsigned.tar.gz
2d8a9d12aadcf60634db953fcb8bd496a002608e9a64eb7d60bb7ffe1f94489f guix-build-58a9601dffa6/output/x86_64-apple-darwin/bitcoin-58a9601dffa6-x86_64-apple-darwin.tar.gz
10363729ece6e1c2cbdf435483006191bf17d1def2d318ff8357197d91c06ded guix-build-58a9601dffa6/output/x86_64-linux-gnu/SHA256SUMS.part
d50ec8e4f72e8b064b196eb0ece212f7b0b126f4b8b644c4451084cbf0416072 guix-build-58a9601dffa6/output/x86_64-linux-gnu/bitcoin-58a9601dffa6-x86_64-linux-gnu-debug.tar.gz
471e12b8715ecff4d99121c4bb3288ef4b005ca468810a714c67ea3e7c6669e9 guix-build-58a9601dffa6/output/x86_64-linux-gnu/bitcoin-58a9601dffa6-x86_64-linux-gnu.tar.gz
d63946401952d131fdf5df9442c52151d86e53f019234b5ad16fdef0d2976356 guix-build-58a9601dffa6/output/x86_64-w64-mingw32/SHA256SUMS.part
5359782e1eb6f449338f18e053ad82f25382d968690208ae5739d9338eb7bdc7 guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64-debug.zip
0d387d5a4cb1d712556a3fe5b4bd1e928bb5fbbe57a85ee06c746f132a6b1ec5 guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64-setup-unsigned.exe
dbfd7419d1d764e853a9dc041e276669b488aea4a80e21e4a175b6c3e512e70c guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64-unsigned.tar.gz
0ba07504d9d5a12af9144e8b386b2640b48dba067d47c694a44ecffe56b0c0fc guix-build-58a9601dffa6/output/x86_64-w64-mingw32/bitcoin-58a9601dffa6-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK 58a9601dff
Tree-SHA512: d1c22b3d0d21ef8f9f605ef6ca06353e3f48536d84f3531f93d613a6ccbbe62f12fae0ed09e8b9a8940b0ef33f9d41d9991eb56fbe7c4ab48f0ce7fcf44e08b1
Define (and document) `NOMINMAX` once, rather than across multiple
source files.
Defining this prevents the definition of min/max macros when using
mingw-w64, which may conflict with unprefixed std::min/max usage. While
that might not be the case for us, we'd always prefer to use the standard
library in any case.
For example:
73cadc06c6/mingw-w64-headers/include/ntdef.h (L289-L300)
Andrew Chow