* Squashed 'src/dashbls/' content from commit 66ee820fbc
git-subtree-dir: src/dashbls
git-subtree-split: 66ee820fbc9e3b97370db8c164904af48327a124
* build: stop tracking build-system generated relic_conf.h.in
* build: add support for building bls-signatures from local subtree
* build: add exclusions to linting scripts and filters
* build: drop bls-signatures (bls-dash) from depends
880d4aaf81f3d5d7fbb915905c2e61b816a6a747 build: use BOOST_NO_CXX98_FUNCTION_BASE to suppress warnings (fanquake)
1bdbbbdc46c4e50bf07bc362e7e391ea1a53ea2f build: suppress array-bounds errors in libxkbcommon (fanquake)
Pull request description:
2 changes to better support building with GCC 12, which out of the box, is currently broken if you want to build using depends.
Prevent `-Warray-bounds` errors when building libxkbcommon. i.e:
```bash
src/xkbcomp/ast-build.c:82:27: error: array subscript 'ExprDef[0]' is partly outside array bounds of 'unsigned char[32]' [-Werror=array-bounds]
82 | expr->expr.value_type = type;
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~
src/xkbcomp/ast-build.c:75:21: note: object of size 32 allocated by 'malloc'
75 | ExprDef *expr = malloc(size);
| ^~~~~~~~~~~~
```
It might be the case that these would be fixed by updating the
package, but that would also require installing new build tools (meson),
as well as potentially more dependencies (wayland), and it'd need
testing with Qt. For now, just turn the errors into wanrings.
Define `BOOST_NO_CXX98_FUNCTION_BASE` to prevent GCC warning about the use of `std::unary_function`. i.e:
```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
```
Boost `container_hash` (included via functional -> multi_index) uses
[`std::unary_function`, which was deprecated in C++11](https://en.cppreference.com/w/cpp/utility/functional/unary_function), and "removed" in
C++17. It's use causes warnings with newer compilers, i.e GCC 12.1.
Use the MACRO outlined in https://github.com/boostorg/container_hash/issues/22, and added to Boost Config for GCC 12 in https://github.com/boostorg/config/pull/430, to prevent it's use.
[BOOST_NO_CXX98_FUNCTION_BASE](https://www.boost.org/doc/libs/master/libs/config/doc/html/boost_config/boost_macro_reference.html):
> 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.
Guix Build (x86_64):
```bash
```
Guix Build (arm64):
```bash
```
ACKs for top commit:
laanwj:
Code review ACK 880d4aaf81f3d5d7fbb915905c2e61b816a6a747
Tree-SHA512: 10c4679c3eb788e9279acc4960731c55ae1568bd3df525d3c46f97d8b0319e7d8450b1638b6777d98111b5991dba5c787e95d80b1ac932e0b4779d4b8e74875e
2525c096b002a89d4c561e1474800496ad8ebd7e build: remove configure checks for win libraries we don't link against (fanquake)
Pull request description:
While cross compiling, `HOST=x86_64-w64-mingw32`, none of these libs actually seem to be passed to the linker. i.e tailing a build with `make -j5 V=1 | rg -i 'mingwthrd|winspool|rpcrt4|crypt32'`.
I'm not 100% sure about `crypt32`, even though the majority of our Windows cryptography usage, i.e [`CryptAcquireContextW`](https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptacquirecontextw) or [`CryptGenRandom`](https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgenrandom) is provided by `advapi32`.
Note that `rpcrt4` and `mingwthrd` are already missing from the MSVC build, so we can sync the remainder once it's clear what's actually needed. Hopefully sipsorcery can add some MSVC insight.
ACKs for top commit:
practicalswift:
ACK 2525c096b002a89d4c561e1474800496ad8ebd7e -- diff looks correct
sipsorcery:
ACK 2525c096b002a89d4c561e1474800496ad8ebd7e.
Tree-SHA512: c756618f85ce2ab1e14e5514dbdc490d94c1c6dfd7a3e3d3b16344ae302fb789585dd10b5c2d784f961f3115bec1d914615051b3184bea00dfbcc3c23884ab4a
4783115fd4cccb46a7f8c592b34fa7c094c29410 net: add ifaddrs.h include (fanquake)
879215e665a9f348c8d3fa92701c34065bc86a69 build: check if -lsocket is required with *ifaddrs (fanquake)
87deac66aa747481e6f34fc80599e1e490de3ea0 rand: only try and use freeifaddrs if available (fanquake)
Pull request description:
Fixes#21485 by linking against `-lsocket` when it's required for using `*ifaddrs` functions.
ACKs for top commit:
laanwj:
Code review ACK 4783115fd4cccb46a7f8c592b34fa7c094c29410
hebasto:
ACK 4783115fd4cccb46a7f8c592b34fa7c094c29410, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: 4542e036e9b029de970eff8a9230fe45d9204bb22313d075f474295d49bdaf1f1cbb36c0c6e2fa8dbbcdba518d8d3a68a6116ce304b82414315f333baf9af0e4
It's a shared library, so we should keep its name and API
distinguishable from Bitcoin's and avoid pkgconfig confusion
Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
e959b46aa933856e7636557f4ec6fce0efbc76aa build: explicitly disable libsecp256k1 openssl based tests (fanquake)
Pull request description:
Backport of #23314
These tests are failing when run against OpenSSL 3, and have been
removed upstream, bitcoin-core/secp256k1#983, so
disabled them for now to avoid `make check` failures.
Note that this will also remove warning output from our build, due to
the use of deprecated OpenSSL API functions. See #23048.
Top commit has no ACKs.
Tree-SHA512: ab3213dc82e7a64a005ce237710009bb447dee2702c4c02245e70df62063a00add73c4e80e9c619ce57345d4a2808fd4dc08e2e02a319b0f3d9285b8b0056599
Co-authored-by: MarcoFalke <falke.marco@gmail.com>
e9f948c72790136656df6056fd9e3698f360e077 build: Convert warnings into errors when testing for -fstack-clash-protection (Hennadii Stepanov)
Pull request description:
Apple clang version 12.0.5 (clang-1205.0.22.9) that is a part of Xcode 12.5, and is based on LLVM clang 11.1.0, fires spammy warnings:
```
clang: warning: argument unused during compilation: '-fstack-clash-protection' [-Wunused-command-line-argument]
```
From the https://github.com/apple/llvm-project:
```
$ git log --oneline | grep 'stack-clash-protection'
00065d5cbd02 Revert "-fstack-clash-protection: Return an actual error when used on unsupported OS"
4d59c8fdb955 -fstack-clash-protection: Return an actual error when used on unsupported OS
df3bfaa39071 [Driver] Change -fnostack-clash-protection to -fno-stack-clash-protection
68e07da3e5d5 [clang][PowerPC] Enable -fstack-clash-protection option for ppc64
515bfc66eace [SystemZ] Implement -fstack-clash-protection
e67cbac81211 Support -fstack-clash-protection for x86
454621160066 Revert "Support -fstack-clash-protection for x86"
0fd51a4554f5 Support -fstack-clash-protection for x86
658495e6ecd4 Revert "Support -fstack-clash-protection for x86"
e229017732bc Support -fstack-clash-protection for x86
b03c3d8c6209 Revert "Support -fstack-clash-protection for x86"
4a1a0690ad68 Support -fstack-clash-protection for x86
f6d98429fcdb Revert "Support -fstack-clash-protection for x86"
39f50da2a357 Support -fstack-clash-protection for x86
```
I suppose, that Apple clang-1205.0.22.9 ends with on of the "Revert..." commits.
This PR prevents using of the `-fstack-clash-protection` flag if it causes warnings.
---
System: macOS Big Sur 11.3 (20E232).
ACKs for top commit:
jarolrod:
re-ACK e9f948c72790136656df6056fd9e3698f360e077
Sjors:
tACK e9f948c72790136656df6056fd9e3698f360e077 on macOS 11.3.1
Tree-SHA512: 30186da67f9b0f34418014860c766c2e7f622405520f1cbbc1095d4aa4038b0a86014d76076f318a4b1b09170a96d8167c21d7f53a760e26017f486e1a7d39d4
7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8 build: don't try and use -fstack-clash-protection on Windows (fanquake)
Pull request description:
This has never worked with any of the mingw-w64 compilers we use, and the `-O0` is causing issues for builders applying spectre mitigations (see [IRC logs](http://www.erisian.com.au/bitcoin-core-dev/log-2021-03-12.html#l-15)).
Recent discussion on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90458 would also indicate that this should just not be used on Windows.
ACKs for top commit:
laanwj:
Concept and code review ACK (but untested) 7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8
hebasto:
ACK 7b3434f8002d1a8cf0dbd0a0caef28e783b1efd8, I've verified that this change does not affect builds for `HOST=x86_64-w64-mingw32` by comparing sizes of the output `*.exe` files.
Tree-SHA512: 72b582321ddff8db3201460fa42a53304e70f141ae078d76a4d4eeb1ca27c8dd567ccb468cc8616179c8df784bd8ca038dcb9a277f9e29f9d98c3cc842916b18
e9189a750b237eba1befc6b16c12c2cee3e0176c build: more robustly check for fcf-protection support (fanquake)
Pull request description:
When using Clang 7, we may end up trying to use the flag when it won't
work properly, which can lead to confusing errors. i.e:
```bash
/usr/bin/ld: error: ... <corrupt x86 feature size: 0x8>
```
Use `AX_CHECK_LINK_FLAG` & `--fatal-warnings` to ensure we wont use the flag in this case.
We do this as even when the error is emitted, compilation succeeds, and the binaries produced will run. This means we can't just check if the compiler accepts the flag, or if compilation succeeds (without or without `-Werror`, and/or passing `-Wl,--fatal-warnings`, which may not be passed through to the linker).
This was reported by someone configuring for fuzzing, on Debian 10, where Clang 7 is the default.
See here for a minimal example of the problematic behaviour:
https://gist.github.com/fanquake/9b33555fcfebef8eb8c0795a71732bc6
ACKs for top commit:
pstratem:
tested ACK e9189a750b237eba1befc6b16c12c2cee3e0176c
MarcoFalke:
not an ACK e9189a750b237eba1befc6b16c12c2cee3e0176c , I only tested configure on my system (gcc-10, clang-11):
hebasto:
ACK e9189a750b237eba1befc6b16c12c2cee3e0176c, tested with clang-7, clang-10 and gcc: the `-fcf-protection=full` is not applied for clang-7, but applied for others compilers.
Tree-SHA512: ec24b0cc5523b90139c96cbb33bb98d1e6a24d858c466aa7dfb3c474caf8c50aca53e570fdbc0ff88378406b0ac5d687542452637b1b5fa062e829291b886fc1
d3ef947524a07f8d7fbad5b95781ab6cacb1cb49 build: Check that Homebrew's berkeley-db4 package is actually installed (Hennadii Stepanov)
Pull request description:
On master (a0489f3472f3799dc1ece32a59556fd239c4c14b) the `configure` script is not able to determine that Homebrew's `berkeley-db4` package is uninstalled. This causes a compile error on macOS.
With this PR, and with the [uninstalled](https://stackoverflow.com/questions/20802320/detect-if-homebrew-package-is-installed) `berkeley-db4` package:
```
% ./configure -q
configure: error: libdb_cxx headers missing, Bitcoin Core requires this library for BDB wallet support (--without-bdb to disable BDB wallet support)
```
Related #20478.
ACKs for top commit:
promag:
Tested ACK d3ef947524a07f8d7fbad5b95781ab6cacb1cb49.
willcl-ark:
tACK d3ef947524a07f8d7fbad5b95781ab6cacb1cb49
jonasschnelli:
utACK d3ef947524a07f8d7fbad5b95781ab6cacb1cb49
Tree-SHA512: 8dc532e08249ec63bd357594aa458d314b6e8537fc63f5b1d509c84d0d71d5b1f70172caa1a7efe2fc8af31c829e7982a0695cf3fbe5cbc477019550269915e1
982e548a9a78b1b0abad59b54c780b6b06570452 Don't set BDB flags when configuring without (Jonas Schnelli)
Pull request description:
Configuring `--without-bdb` on MacOS leads to a compile error (when BerkeleyDB is not installed). `brew --prefix berkeley-db4` always reports the target directory (even if not installed).
This PR prevents BDB_CFLAGS (et al) from being populated when configuring `--without-bdb`
```
ld: warning: directory not found for option '-L/Users/user/Documents/homebrew/Cellar/berkeley-db@4/4.8.30/lib'
ld: warning: directory not found for option '-L/Users/user/Documents/homebrew/Cellar/berkeley-db@4/4.8.30/lib'
ld: library not found for -ldb_cxx-4.8
ld: library not found for -ldb_cxx-4.8
```
ACKs for top commit:
promag:
Tested ACK 982e548a9a78b1b0abad59b54c780b6b06570452.
hebasto:
ACK 982e548a9a78b1b0abad59b54c780b6b06570452, tested on macOS 11 Big Sur.
Tree-SHA512: f8ca0adca0e18e2de4c0f99d5332cba70d957a9d31a357483b43dcf61c2ed4749d223eabadd45fdbf3ef0781c6b37217770e9aa935b5207eaf7f87c5bdfe9e95
b536813cefc13f5c54a28a7c2fce8c69e89d6624 build: add -fstack-clash-protection to hardening flags (fanquake)
076183b36b76a11438463883ff916f17aef9e001 build: add -fcf-protection=full to hardening options (fanquake)
Pull request description:
Beginning with Ubuntu `19.10`, it's packaged GCC now has some additional hardening options enabled by default (in addition to existing defaults like `-fstack-protector-strong` and reducing the minimum ssp buffer size). The new additions are`-fcf-protection=full` and `-fstack-clash-protection`.
> -fcf-protection=[full|branch|return|none]
> Enable code instrumentation of control-flow transfers to increase program security by checking that target addresses of control-flow transfer instructions (such as indirect function call, function return, indirect jump) are valid. This prevents diverting the flow of control to an unexpected target. This is intended to protect against such threats as Return-oriented Programming (ROP), and similarly call/jmp-oriented programming (COP/JOP).
> -fstack-clash-protection
> Generate code to prevent stack clash style attacks. When this option is enabled, the compiler will only allocate one page of stack space at a time and each page is accessed immediately after allocation. Thus, it prevents allocations from jumping over any stack guard page provided by the operating system.
If your interested you can grab `gcc-9_9.3.0-10ubuntu2.debian.tar.xz` from https://packages.ubuntu.com/focal/g++-9. The relevant changes are part of the `gcc-distro-specs` patches, along with the relevant additions to the gcc manages:
> NOTE: In Ubuntu 19.10 and later versions, -fcf-protection is enabled by default for C, C++, ObjC, ObjC++, if none of -fno-cf-protection nor -fcf-protection=* are found.
> NOTE: In Ubuntu 19.10 and later versions, -fstack-clash-protection is enabled by default for C, C++, ObjC, ObjC++, unless -fno-stack-clash-protection is found.
So, if you're C++ using GCC on Ubuntu 19.10 or later, these options will be active unless you explicitly opt out. This can be observed with a small test:
```c++
int main() { return 0; }
```
```bash
g++ --version
g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0
g++ test.cpp
objdump -dC a.out
..
0000000000001129 <main>:
1129: f3 0f 1e fa endbr64
112d: 55 push %rbp
112e: 48 89 e5 mov %rsp,%rbp
1131: b8 00 00 00 00 mov $0x0,%eax
1136: 5d pop %rbp
1137: c3 retq
1138: 0f 1f 84 00 00 00 00 nopl 0x0(%rax,%rax,1)
113f: 00
# recompile opting out of control flow protection
g++ test.cpp -fcf-protection=none
objdump -dC a.out
...
0000000000001129 <main>:
1129: 55 push %rbp
112a: 48 89 e5 mov %rsp,%rbp
112d: b8 00 00 00 00 mov $0x0,%eax
1132: 5d pop %rbp
1133: c3 retq
1134: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
113b: 00 00 00
113e: 66 90 xchg %ax,%ax
```
Note the insertion of an `endbr64` instruction when compiling and _not_ opting out. This instruction is part of the Intel Control-flow Enforcement Technology [spec](https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf), which the GCC control flow implementation is based on.
If we're still doing gitian builds for the `0.21.0` and `0.22.0` releases, we'd likely update the gitian image to Ubuntu Focal, which would mean that the GCC used for gitian builds would also be using these options by default. So we should decide whether we want to explicitly turn these options on as part of our hardening options (although not just for this reason), or, we should be opting-out.
GCC has supported both options since 8.0.0. Clang has supported `-fcf-protection` from 7.0.0 and will support `-fstack-clash-protection` in it's upcoming [11.0.0 release](https://clang.llvm.org/docs/ReleaseNotes.html#id6).
ACKs for top commit:
jamesob:
ACK b536813cefc13f5c54a28a7c2fce8c69e89d6624 ([`jamesob/ackr/18921.1.fanquake.build_add_stack_clash_an`](https://github.com/jamesob/bitcoin/tree/ackr/18921.1.fanquake.build_add_stack_clash_an))
laanwj:
Code review ACK b536813cefc13f5c54a28a7c2fce8c69e89d6624
Tree-SHA512: abc9adf23cdf1be384f5fb9aa5bfffdda86b9ecd671064298d4cda0440828b509f070f9b19c88c7ce50ead9ff32afff9f14c5e78d75f01241568fbfa077be0b7
8578c6fccd11404412d2c60f9bede311b79ca0d0 build: Fix search for brew-installed BDB 4 on OS X (Glenn Willen)
Pull request description:
~~NOTE: This PR contains one important fix that I need (to make Bitcoin Core build cleanly on my system without shenanigans), plus some related general cleanup that is not really necessary, and could be annoying. (I am prepared to defend my argument that BDB_CFLAGS is wrong here, and BDB_CPPFLAGS is right, but this could bite anybody who has gotten in the habit of -- or scripted -- setting the former.)~~
Ok, I have been convinced that I was too clever with the refactor and I have removed it. Now it's just the tiny change to fix the build on my local machine.
---
On OS X, when searching Homebrew keg-only packages for BDB 4.8, if we find it,
use BDB_CPPFLAGS and BDB_LIBS instead of CFLAGS and LIBS for the result. This
is (1) more correct, and (2) necessary in order to give this location
priority over other directories in the include search path, which may include
system include directories with other versions of BDB.
ACKs for top commit:
theuni:
ACK 8578c6fccd11404412d2c60f9bede311b79ca0d0.
Tree-SHA512: a28f48fc81a25736f7e77c663f21cd9a6ae1cd115682031c5aa695c94cb5afa11920330a60cd6a54832822a2aec1eb23123ac2e2dcd4f0b3835aef9c9339ac97
b155fcda5186c59fc4fb2a9eaaf791d132e0ab30 doc: fix typo in configure.ac (fanquake)
20a30922fbf6ba14e250ca649239af115dbbe7b0 doc: note why we can't use thread_local with glibc back compat (fanquake)
Pull request description:
Given that we went through a [gitian build](https://github.com/bitcoin/bitcoin/pull/18681) to remember why this is the case, we might as well make a note of it in configure.ac.
[From #18681](https://github.com/bitcoin/bitcoin/pull/18681#issuecomment-615526634):
Looking at the Linux build log, this has failed with:
```bash
Checking glibc back compat...
bitcoind: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
bitcoind: failed IMPORTED_SYMBOLS
bitcoin-cli: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
bitcoin-cli: failed IMPORTED_SYMBOLS
bitcoin-tx: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
bitcoin-tx: failed IMPORTED_SYMBOLS
bitcoin-wallet: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
bitcoin-wallet: failed IMPORTED_SYMBOLS
test/test_bitcoin: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
test/test_bitcoin: failed IMPORTED_SYMBOLS
bench/bench_bitcoin: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
bench/bench_bitcoin: failed IMPORTED_SYMBOLS
qt/bitcoin-qt: symbol __cxa_thread_atexit_impl from unsupported version GLIBC_2.18
```
`__cxa_thread_atexit_impl` is used for [thread_local variable destruction](https://sourceware.org/glibc/wiki/Destructor%20support%20for%20thread_local%20variables):
> To implement this support, glibc defines __cxa_thread_atexit_impl exclusively for use by libstdc++ (which has the __cxa_thread_atexit to wrap around it), that registers destructors for thread_local variables in a list. Upon thread or process exit, the destructors are called in reverse order in which they were added.
As suggested, this only became available in glibc 2.18. From the [2.18 release notes](https://sourceware.org/legacy-ml/libc-alpha/2013-08/msg00160.html):
> * Add support for calling C++11 thread_local object destructors on thread
and program exit. This needs compiler support for offloading C++11
destructor calls to glibc.
ACKs for top commit:
hebasto:
ACK b155fcda5186c59fc4fb2a9eaaf791d132e0ab30
Tree-SHA512: 5b9567e4a70598a4b0b91956f44ae0d93091db17c84cbf9817dac6cfa992c97d3438a8b1bb66644c74891f2149e44984daed445d22de93ca8858c5b0eabefb40
d76894987d0277e8011932ab7dfd77c537f8ea6e logging: enable thread_local usage on macOS (fanquake)
Pull request description:
Now that we're building against a newer SDK (`10.14`), we should be able to enable `thread_local` usage on macOS. Have tested building and running locally, as well as cross-compiling and running the binaries on a macOS 10.14 system.
#### master 8a56f79d491271120abc3843c46e9dda44edd308
```bash
src/bitcoind -logthreadnames=1
2020-02-06T04:38:33Z [] Bitcoin Core version v0.19.99.0-8a56f79d4 (release build)
2020-02-06T04:38:33Z [] Assuming ancestors of block 00000000000000000005f8920febd3925f8272a6a71237563d78c2edfdd09ddf have valid signatures.
2020-02-06T04:38:33Z [] Setting nMinimumChainWork=000000000000000000000000000000000000000008ea3cf107ae0dec57f03fe8
2020-02-06T04:38:33Z [] Using the 'sse4(1way),sse41(4way),avx2(8way)' SHA256 implementation
2020-02-06T04:38:33Z [] Using RdSeed as additional entropy source
```
#### this PR d76894987d0277e8011932ab7dfd77c537f8ea6e
```bash
checking for thread_local support... yes
...
src/bitcoind -logthreadnames=1
2020-02-06T04:17:49Z [net] net thread start
2020-02-06T04:17:49Z [opencon] opencon thread start
2020-02-06T04:17:49Z [dnsseed] dnsseed thread start
2020-02-06T04:17:49Z [init] init message: Done loading
2020-02-06T04:17:49Z [msghand] msghand thread start
2020-02-06T04:17:49Z [addcon] addcon thread start
...
2020-02-06T04:17:54Z [init] tor: Thread interrupt
2020-02-06T04:17:54Z [init] Shutdown: In progress...
```
From the [Xcode 8 release notes](https://developer.apple.com/library/archive/releasenotes/DeveloperTools/RN-Xcode/Chapters/Introduction.html#//apple_ref/doc/uid/TP40001051-CH1-SW78)
> C++ now supports the thread_local keyword, which declares thread-local storage (TLS) and supports C++ classes with non-trivial constructors and destructors. (9001553)
ACKs for top commit:
jonasschnelli:
Tested ACK d76894987d0277e8011932ab7dfd77c537f8ea6e
nijynot:
ACK d768949
hebasto:
ACK d76894987d0277e8011932ab7dfd77c537f8ea6e
Tree-SHA512: 48f3e4104b80bd7b6aedcef10bb1957b073530130f33af7c5cb59e876ac3f5480e53d7af1c0b226d809fe9eef1add3d6c3fb6de4af174966202c6030060ea823
