CI Builder Updates & Refactors
To support existing legacy pinned Docker builder/workers in Buildbot, it is valuable to move these into their own folder.
The new directory structured is intended to simplify development/deployment of Docker Tekton builder/worker images and remove overhead related to potential Buildbot CI depreciation.
This enables of the use of AI_* definitions in the Windows headers,
specifically AI_ADDRCONFIG, which fixes an issue with libevent and
ipv6 on Windows.
It also aligns with what we define in configure when building Core.
(cherry picked from commit eb6b73540d1ee7ff5a6874dd0e35f9b30b68e3b8)
libevent uses getaddrinfo when available, and falls back to gethostbyname
Windows has both, but gethostbyname only supports IPv4
libevent fails to detect Windows's getaddrinfo due to not including the right headers
This patches libevent's configure script to check it correctly
(cherry picked from commit 03e056edcd1a7f7197a29068c52fa33fce12f7d7)
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 PR intends to resolve#15227.
"configure --debug-enabled" enables "#ifdef DEBUG_LOCKORDER".
Then "lockdata" (in sync.cpp) will be initialized same as other
static objects.
But unfortunately, lockdata.push_lock() was called before its
initialization (via initializing signatureCache which is declared
in script/sigcache.cpp) on macOS.
This PR apply the "Construct On First Use Idiom" to "lockdata"
to prevent it.
(cherry picked from commit b09dab0f2de37be3c96f5087ee7bd61d7262aa76)
These were merged in an old PR that was created before we backported
src/fs.h.
-BEGIN VERIFY SCRIPT-
sed -i 's/boost::filesystem/fs/g' ./src/addrdb.*
-END VERIFY SCRIPT-
zcash: Not an actual locking fix; just eliminates unnecessary recursive
zcash: locking (which is a long-term goal).
zcash: cherry picked from commit 1beea7af92994dca83facb11bbef82b24b538400
zcash: https://github.com/bitcoin/bitcoin/pull/12333
This resolves an issue where getrawmempool() can race mempool
notification signals. Intuitively we use mempool.cs as a "read
lock" on the mempool with cs_main being the write lock, so holding
the read lock intermittently while doing write operations is
somewhat strange.
This also avoids the introduction of cs_main in getrawmempool()
which reviewers objected to in the previous fix in #12273
zcash: cherry picked from commit 85aa8398f5d13c659299b81cdae377462b4f8316
zcash: https://github.com/bitcoin/bitcoin/pull/12368
The HTTP worker thread counter, as well as the RAII object that was used
to maintain it, is unused now, so can be removed.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
zcash: cherry picked from commit 11e01515fe0fbc7823d4111ad6e016a02c485a78
zcash: https://github.com/bitcoin/bitcoin/pull/12366
This function, which waits for all threads to exit, is no longer needed
now that threads are joined instead.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
zcash: cherry picked from commit f94665466ed50e868c98b1a1c708ad5767727bb6
zcash: https://github.com/bitcoin/bitcoin/pull/12366
This prevents a potential race condition if control flow ends up in
`ShutdownHTTPServer` before the thread gets to `queue->Run()`,
deleting the work queue while workers are still going to use it.
Meant to fix#12362.
Signed-off-by: Wladimir J. van der Laan <laanwj@gmail.com>
zcash: cherry picked from commit b1c2370dde9ade180c638e5d9a4797f085322b5b
zcash: https://github.com/bitcoin/bitcoin/pull/12366