To successfully call the `capnp_generate_cpp()` function, the
`libmultiprocess` build system must be provided with paths to the native
`capnp` and `capnpc-c++` tools.
When no build dir is specified, cmake will warn:
```bash
Preprocessing libmultiprocess...
Configuring libmultiprocess...
CMake Warning:
No source or binary directory provided. Both will be assumed to be the
same as the current working directory, but note that this warning will
become a fatal error in future CMake releases.
```
It's unclear if this will actually ever become an error, but it's also easy
enough to just supply the directory, and save this maybe breaking in
future.
Qt 5.15.3 release is a patch release made on the top of Qt 5.15.2. As a patch
release, Qt 5.15.3 does not add any new functionality but provides bug fixes
and other improvements.
https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.3/release-note.md
* dropped patches:
- patches/qt/dont_use_avx_android_x86_64.patch
- patches/qt/fix_bigsur_style.patch
* adjusted patches:
- patches/qt/fix_android_jni_static.patch
- patches/qt/fix_limits_header.patch
- patches/qt/use_android_ndk23.patch
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
This is currently causing the same failure in two different PRs:
```bash
duplicate symbol 'lcQpaFonts()' in:
/tmp/cirrus-ci-build/depends/x86_64-apple-darwin/lib/libQt5ThemeSupport.a(qgenericunixthemes.o)
/tmp/cirrus-ci-build/depends/x86_64-apple-darwin/lib/libQt5FontDatabaseSupport.a(qfontengine_coretext.o)
ld: 1 duplicate symbol for architecture x86_64
```
```bash
x86_64-apple-darwin-ld: error: duplicate symbol: __Z10lcQpaFontsv
>>> defined in /tmp/cirrus-ci-build/depends/x86_64-apple-darwin/lib/libQt5ThemeSupport.a(qgenericunixthemes.o)
>>> defined in /tmp/cirrus-ci-build/depends/x86_64-apple-darwin/lib/libQt5FontDatabaseSupport.a(qfontengine_coretext.o)
```
Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>
We don't use the deprecated headers now, and never should do in the
future, so there is no need for them to exist in depends.
The headers themselves are just full of includes for the newer headers.
This primarily improves support for external signing, as it includes
multiple bugfixes for Boost Process. As well as various improvements to
the multi-index library.
edc9a6afdc build, refactor: Reuse expat package version in its download path (Hennadii Stepanov)
4bb7821ab2 build, refactor: Use conventional version notation for boost package (Hennadii Stepanov)
Pull request description:
`boost` package:
- `.` is used as a separator in versions of other depends packages.
`expat` package:
- reuse package version in its download path
---
The straightforward way to verify this PR:
```
$ cd depends
$ make clean-all
$ make boost_fetched
$ make expat_fetched
```
ACKs for top commit:
prusnak:
ACK edc9a6a
shaavan:
ACK edc9a6afdc
Tree-SHA512: c15d672fe34ac59850425d3d6a6eee5f720e16d227aad1332a563b218465879b7ee6fb865dd1bac06aedf356f9bb1c67112d9d88da8f877f04838b50a9dc97be
9796dcacdc doc: Install only "-posix" MinGW compiler when possible (Hennadii Stepanov)
0bbae237a8 ci: Drop no longer needed `update-alternatives` (Hennadii Stepanov)
01d1845a80 build, qt: Specify QMAKE_CXX explicitly (Hennadii Stepanov)
Pull request description:
While changes introduced in bitcoin/bitcoin#22093 worked fine with Qt 5.12, after bumping Qt up to 5.15 the cross-compiling of `qt` package for Windows fails with `error: ‘mutex’ in namespace ‘std’ does not name a type`.
The first commit fixes this bug.
The second commit cleans up a related CI script.
The third commit improves related docs (see https://github.com/bitcoin/bitcoin/pull/22093#discussion_r680911586).
ACKs for top commit:
prusnak:
ACK 9796dca
Tree-SHA512: 0dc46c5dfab85bd6d2901052cd630e86f9b4e09c08ef87136b44ddecb1783cdf3cd0a6e67b95ac7a78da24cd7adedc88745f61f9a8d9993fbff26d33bf88d874
01e121d290 depends: fix capnp's descriptor for make download (Cory Fields)
Pull request description:
The non-native capnp was trying to fetch the wrong file.
Without this, "make -C depends MULTIPROCESS=1 download" is broken.
Presumably it breaks with the download target because the dependency graph is flattened. It manages to work if native_capnp is encountered first because it will then be found in the cache.
ACKs for top commit:
gruve-p:
tACK 01e121d290
hebasto:
ACK 01e121d290, tested on Linux Mint 20.2 (x86_64).
Tree-SHA512: 2605d895f3799be5a311f6f7d36a5c13cdb715dc148915ad818f4afc7d5de92cd6b8ecd34ff2b21cef6743b090819bba1e3353096cfb5659c55f76113ce5adf3
ae9175f608 build: add FreeBSD support to depends (fanquake)
Pull request description:
Setup to use the system Clang (11.0.1 as of FreeBSD 13.0).
Doesn't build the Qt package; that requires a few additional changes. The current issue is that FreeBSDs `byacc` seems to have an issue parsing something in libxkbcommon. Work in progress branch here: https://github.com/fanquake/bitcoin/tree/depends_support_freebsd_qt. In any case, I don't think building the Qt libs on FreeBSD is a super high priority (I'd also have no way to test the GUI).
ACKs for top commit:
laanwj:
ACK ae9175f608
Tree-SHA512: 1ecc7855f0195f68c96e534bd77ce17c3975db1dfb3caa35302c2b46643c8c30f75b1c2e1735cf69f1eddb70447d11e67e7f339ef5497336cdff7a59b32be961
The non-native capnp was trying to fetch the wrong file.
Without this, "make -C depends MULTIPROCESS=1 download" is broken.
Presumably it breaks with the download target because the dependency graph is
flattened. It manages to work if native_capnp is encountered first because it
will then be found in the cache.
f13e642c83 build: Disable valgrind when building zeromq package in depends (Hennadii Stepanov)
b970f03bea build: Disable libbsd when building zeromq package in depends (Hennadii Stepanov)
77899991b1 build: Update netbsd_kevent_void.patch (Hennadii Stepanov)
Pull request description:
Since v4.3.3 (068385c951) `libzmq` uses `libbsd` by default.
This PR disables `libbsd` explicitly, as it's not a part of our depends. Zeromq will fallback to its internal `strlcpy` implementation.
Otherwise, on systems with installed `libbsd-dev` package the `zeromq` package build system erroneously detects `libbsd` package from the host system:
```diff
--- a/libzmq.pc
+++ b/libzmq.pc
@@ -8,5 +8,5 @@
Version: 4.3.4
Libs: -L${libdir} -lzmq
Libs.private: -lpthread
-Requires.private:
+Requires.private: libbsd
Cflags: -I${includedir}
```
This causes the `configure` fails to detect the `zeromq` package:
```
configure: WARNING: libzmq version 4.x or greater not found, disabling
```
---
Other minor improvements:
- fixed `netbsd_kevent_void.patch` offset
- disabled valgrind as it's used in unit tests which we do not run:
```diff
--- a/zmq-configure-output
+++ b/zmq-configure-output
@@ -119,11 +119,6 @@
checking whether the g++ -m64 linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
-checking for valgrind... valgrind
-checking for Valgrind tool memcheck... memcheck
-checking for Valgrind tool helgrind... helgrind
-checking for Valgrind tool drd... drd
-checking for Valgrind tool exp-sgcheck... exp-sgcheck
checking linker version script flag... --version-script
checking if version scripts can use complex wildcards... yes
checking for working posix_memalign... yes
```
ACKs for top commit:
fanquake:
ACK f13e642c83
Tree-SHA512: d4c86d4a841eb6e7c32157e84972243072f905496c2a4c14ec6f6ab4216df6695cbf29baa2233ce27eaede35d1e250ad2f9975b16f570d01509f0c5da4597cad
Since v4.3.3 (068385c951c0608edec6264d55ba9c4c923acccc) libbsd is used
by default. As we have no libbsd package in our depends, disable it
explicitly. Zeromq will fallback to its internal strlcpy implementation.
6897c4bdf5 build: patch depends zeromq to fix building on NetBSD Current (fanquake)
ce6dd2f1a2 zeromq 4.3.4 (fanquake)
Pull request description:
This is a prerequisite for #23955. It updates zeromq to the latest available version, and adds a patch, [that I've sent upstream](https://github.com/zeromq/libzmq/pull/4326), to fix building on NetBSD Current (10).
ACKs for top commit:
hebasto:
ACK 6897c4bdf5, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: d05d9753630faebe842e1ca70c8c4af660a38e7331a9d95e84df3a3b14564c5118ca41c4fc49fb71dfee563b63e1014e5a3f8874d652e26de59e8e188a12970e
Similar to how we specify the OS's we build Qt for, specify which OS's
we will build qrencode for (a qt dependency). This commit alone doesn't
change anything, but when we start supporting other OS's, i.e #23948,
where we wont support qt (or at least initially), it'll skip building
the qrencode package, which would be unused.
6200fbf54f build: rename --enable-ebpf to --enable-usdt (0xb10c)
e158a2a7aa build: add systemtap's sys/sdt.h as depends (0xb10c)
Pull request description:
There has been light conceptual agreement on including the Userspace, Statically Defined Tracing tracepoints in Bitcoin Core release builds. This, for example, enables user to hook into production deployments, if they need to. Binaries don't have to be switched out. This is possible because we don't do [expensive computations](https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md#no-expensive-computations-for-tracepoints) only needed for the tracepoints. The tracepoints are NOPs when not used.
Systemtap's `sys/sdt.h` header is required to build Bitcoin Core with USDT support. The header file defines the `DTRACE_PROBE` macros used in [`src/util/trace.h`](https://github.com/bitcoin/bitcoin/blob/master/src/util/trace.h). This PR adds Systemtap 4.5 (May 2021) as dependency. GUIX builds for Linux hosts now include the tracepoints.
Closes https://github.com/bitcoin/bitcoin/issues/23297.
ACKs for top commit:
fanquake:
ACK 6200fbf54f - tested enabling / disabling and with/without SDT from depends. We can follow up with #23819, #23907 and #23296, and if any serious issues arise before feature freeze, it is easy for us to flip depends such that USDT becomes opt-in, rather than opt-out, and thus, releases would be tracepoint free.
Tree-SHA512: 0263f44892bf8450e8a593e4de7a498243687f8d81269e1c3283fa8354922c7cf93fddef4b92cf5192d33798424aa5812e03e68ef8de31af078a32dd34021382
This is required so that we can test for control flow in our ELF
security checks. Otherwise test_bitcoin will fail, as it has a main that
is provided by Boost, and wont have been built with
-fcf-protection=full.
While here simplify to using -fcf-protection for all x86_64 builds.
The sys/sdt.h header is required to build Bitcoin Core with Userspace
Statically Defined Tracing support. Systemtap version 4.5 (May 2021)
is used as the most recent version 4.6 (Nov 2021) fails to build.
See e.g. https://sourceware.org/git/?p=systemtap.git;a=commit;h=1d3653936fc1fd13135a723a27e6c7e959793ad0
As Systemtap itself is not needed, the build steps (configure and
make) are skipped. We require fewer build dependecies and don't
waste time building depends we don't end up using. However, the
configure step would normally processes sys/sdt-config.h.in. The
resulting sdt-config.h defines _SDT_ASM_SECTION_AUTOGROUP_SUPPORT
(either 0 or 1 to indicate whether the assembler supports "?" in
.pushsection directives). For now, we assume all currently used
assemblers supports this feature and remove the check from the
sys/sdt.h header file in a patch.
Co-authored-by: Michael Ford <fanquake@gmail.com>
33796a964a build: Add ability to build qt in depends with -stdlib=libc++ (Hennadii Stepanov)
Pull request description:
This PR makes possible to build the `qt` package in depends against `libc++` for x86_64 platform.
Fixes#22344.
Required for #22815.
Also this PR [fixes](https://github.com/bitcoin/bitcoin/pull/23060#discussion_r716077050) the `[no wallet] [bionic]` task on CI:
- on master (a8bbd4cc81), https://api.cirrus-ci.com/v1/task/5558609250615296/logs/ci.log:
```
Options used to compile and link:
external signer = yes
multiprocess = no
with libs = yes
with wallet = no
with gui / qt = no
```
- this PR, https://api.cirrus-ci.com/v1/task/5502605561430016/logs/ci.log:
```
Options used to compile and link:
external signer = yes
multiprocess = no
with libs = yes
with wallet = no
with gui / qt = yes
```
ACKs for top commit:
fanquake:
ACK 33796a964a - While this sort of string matching is fragile, I think the risk of this causing any actual issues is low.
Tree-SHA512: 586dde2e9864cec7a49aeb4f2b77fb8c4ae96bd10b51f9c6de0cfe8512ad61db15bb7f8d1b0eb6a5a66fd2deee52ac52218f01eb6be107ac12f1a956190de54b
66a20a54a2 build, qt: Drop support for `i686-linux-android` host (Hennadii Stepanov)
Pull request description:
There are no reasons to keep support for `i686-linux-android` host, which is actually broken in master (50c502f54a), and this fact has been unnoticed for months :)
https://github.com/bitcoin/bitcoin/pull/23675#issuecomment-986206434:
> I'm surprised `i686-linux-android` ABI is still supported. I would love to drop it...
https://github.com/bitcoin/bitcoin/pull/23675#issuecomment-991340132
> What is `i686-linux-android`? 32-bit x86 android? is that really a thing?
ACKs for top commit:
prusnak:
utACK 66a20a54a2
Tree-SHA512: 211f794de2fc569f0ade2a4da805b8bfd4ce2ab0930c5d427acc4f5d015fcdc4911f02fc64f6401197f7641aed79944a9594be80c817547be3269cdd721cf79b
Since Qt 5.14.0 the CROSS_COMPILE variable always being overridden by
the Qt build system internally.
See upstream commit: c28b881c98fadcd3415370fad2525b558f6b03e4
