Age | Commit message (Collapse) | Author |
|
GUIX builds with USDT tracepoints
6200fbf54fa919899d99f1cdd5ef88ec8b074cd6 build: rename --enable-ebpf to --enable-usdt (0xb10c)
e158a2a7aa501da635cb34414abd0c092216e5f4 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 6200fbf54fa919899d99f1cdd5ef88ec8b074cd6 - 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
|
|
host
2fda0c785188ae94fba921c1b8f6f2c005faf1d4 doc: Drop no longer required notes for Windows builds (Hennadii Stepanov)
f09ed92be132ebcb91b459c87d640a14b4b54336 build: Try posix-specific CXX first for mingw32 host (Hennadii Stepanov)
Pull request description:
On master (1186910b6b7ba7c7e5193c76f33f25825e6cc0b7), when cross-compiling for Windows using our depends build system, we must manually choose the POSIX thread model for the `x86_64-w64-mingw32-g++` compiler.
This PR improves the build system to make this choice automa**g**ically.
ACKs for top commit:
jarolrod:
re-ACK 2fda0c785188ae94fba921c1b8f6f2c005faf1d4
shaavan:
tACK 2fda0c785188ae94fba921c1b8f6f2c005faf1d4
Tree-SHA512: ad3bbdfe84b3c8eb56e102aa0abdc76fd864b2724ac59c9a12a798c57d1c5a1172682172588019d5d1715801a9f201fd9424effbd858e8dc30607c23c0d5941f
|
|
than generating
e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6 build: use a static .tiff for macOS .dmg over generating (fanquake)
Pull request description:
For demonstration, after [discussion in #23778](https://github.com/bitcoin/bitcoin/pull/23778#issuecomment-1003005503), and the question as to why we can't just have a `background.tiff` that we copy into the macOS DMG, and do away with the somewhat convoluted image generation steps.
From my understanding, the only reason we have this image generation as part of our build system is so that forks of Core can adapt the imagery for their own branding via `PACKAGE_NAME`. It don't think it provides much value to us, and could just have a static .tiff that we copy into the dmg (replacing the .svg that currently lives in macdeploy/).
Doing this would eliminate the following build dependencies:
For native macOS:
* `sed` (usage in Makefile.am)
* `librsvg` (rsvg-convert)
* `tiffutil`
Linux macOS cross-compile:
* `sed` (usage in Makefille.am)
* `librsvg`
* `tiffcp`
* `convert` (imagemagick)
* `font-tuffy`
Guix Build:
```bash
bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
c98d67796863f4b1bab0ad600d46bd74e744d94072cbd4bc856a6aeaba3bb329 guix-build-e09773d20a92/output/dist-archive/bitcoin-e09773d20a92.tar.gz
3336f90bab312798cb7665e2b4ae24d1a270fb240647d5fed8dbfcd83e3ed37e guix-build-e09773d20a92/output/x86_64-apple-darwin/SHA256SUMS.part
8fd680c7ee158c64bad212385df7b0b302c6c2143d4e672b4b0eb5da41f9256d guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.dmg
34f54177c2f0700e8cfaf5d85d91e404807cd9d411e22006cdff82653e5f4af2 guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx-unsigned.tar.gz
da6b8f54ef755d40330c8eac4f5bd0329637e827be9ee61318600d5d0bdcc3dc guix-build-e09773d20a92/output/x86_64-apple-darwin/bitcoin-e09773d20a92-osx64.tar.gz
```
![dmg](https://user-images.githubusercontent.com/863730/147847717-8121c2d2-cdd4-4781-8397-3bf2893d52cc.png)
ACKs for top commit:
hebasto:
ACK e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6
jarolrod:
ACK e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6
Zero-1729:
ACK e09773d20a9230ba7aa2cbb7e87fdc5187ddfec6
Tree-SHA512: 0ad06699a5451daa8cfaaa46759eb7bd85254a72e23f857f70d433a2ffb1a4bf6dd464d9c4ac9f8c20aab045f4e2b61c6dcdcbcceef96ce515b1a0c501665b1f
|
|
|
|
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>
|
|
|
|
Co-authored-by: Pavol Rusnak <pavol@rusnak.io>
|
|
-stdlib=libc++
33796a964a8c605ce482959456d1ca78638340d9 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 (a8bbd4cc819633ec50ed0f763b6a75330ae055fb), 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 33796a964a8c605ce482959456d1ca78638340d9 - While this sort of string matching is fragile, I think the risk of this causing any actual issues is low.
Tree-SHA512: 586dde2e9864cec7a49aeb4f2b77fb8c4ae96bd10b51f9c6de0cfe8512ad61db15bb7f8d1b0eb6a5a66fd2deee52ac52218f01eb6be107ac12f1a956190de54b
|
|
d3b0f82a438ae60060d0d4d83245bf75f5de433d build: Fix regression introduced in PR23603 (Hennadii Stepanov)
Pull request description:
It appears 7629efcc2c3a8a8a7c17b1300cd466ec6c8c1f3f from bitcoin/bitcoin#23603 introduced a regression in build tool flag evaluation.
On macOS system:
- pre-PR23603 master (ae017b81604761b57e22c28913c4ce81bf2e31ce):
```
% make -C depends print-darwin_CXXFLAGS
darwin_CXXFLAGS=-pipe
% make -C depends print-host_CXXFLAGS
host_CXXFLAGS=-pipe
```
- the current master (369978686e156ad34df703f1e60bd90aeaa8f2d6):
```
% make -C depends print-darwin_CXXFLAGS
darwin_CXXFLAGS=-pipe
% make -C depends print-host_CXXFLAGS
host_CXXFLAGS=-arch x86_64
```
It's obvious a flag being set in `depends/hosts/darwin.mk`, i.e., `-pipe`, is lost.
With this PR:
```
% make -C depends print-darwin_CXXFLAGS
darwin_CXXFLAGS=-pipe
% make -C depends print-host_CXXFLAGS
host_CXXFLAGS=-pipe -arch x86_64
```
ACKs for top commit:
fanquake:
ACK d3b0f82a438ae60060d0d4d83245bf75f5de433d
Tree-SHA512: 643099ce6858475ac9f3a4dfa72a4e493fec6fdd7042ae0f0d5fe44c5cd175e4eda63cb39fc46ac1501cadcd3466507ec88d9089235e005fe43ea7ab47ce37c1
|
|
Qt RCC
11736dbe3dbe34bcb430d05810b9e9aa66ec1cd6 build, qt: Hardcode last modified timestamp in Qt RCC (Hennadii Stepanov)
Pull request description:
Our Guix build system sets the [`SOURCE_DATE_EPOCH`](https://reproducible-builds.org/specs/source-date-epoch/) and propagates it to the depends build subsystem. Its [default value](https://github.com/bitcoin/bitcoin/blob/master/contrib/guix/README.md#recognized-environment-variables) is the top commit timestamp.
After bumping Qt version up to 5.15.2, due to [this](https://github.com/qt/qtbase/commit/1ffcca4cc208c48ddb06b6a23abf1756f9724351) change, every time they are going to make new Guix builds for another branch/commit they must ensure that the `qt` package will be rebuilt from scratch. Otherwise, Bitcoin Core GUI binaries will be non-deterministic.
Such behavior makes working with Guix builds suboptimal.
This PR fixes the described issue by patching Qt RCC and hardcoding last modified timestamps with `1`.
It's worth to mention that this change is compatible with a possible future [improvement](https://github.com/bitcoin/bitcoin/pull/21995) which makes each dependency package reproducible.
A drawback of such an approach is not currently applied to our project, as it effectively makes [QML cache files](https://bugreports.qt.io/browse/QTBUG-57182) useless. I can't say it's a problem for the https://github.com/bitcoin-core/gui-qml project.
---
**A note for thinkers:** For now this change is enough as only Qt source contains `SOURCE_DATE_EPOCH`. But in general we should re-think about treating the `SOURCE_DATE_EPOCH` variable in the depends build subsystem. For instance, its default value could be the output of `git log --format=%at -1 -- depends`.
ACKs for top commit:
fanquake:
ACK 11736dbe3dbe34bcb430d05810b9e9aa66ec1cd6
Tree-SHA512: 31f104010a0a78d217aafcc5bc4606351f9060fc2a827277935b85fc8ced9f3d90a31d812c7db8c2711fb6daccd279cf0945dc1d7a7199e0eb0ade451cdbcd5d
|
|
This change allows the already built qt package to be reused even with
the SOURCE_DATE_EPOCH variable set, e.g., for Guix builds.
|
|
It is outdated since bitcoin/bitcoin#23060.
|
|
Assignments in builders/darwin.mk actually override previous assignments
in hosts/default.mk. Therefore, the append operator must be used
instead.
|
|
8494dcae0e32716fd7cc7abeacf0a795a1303e6a Replace $(AT) with .SILENCE. (Dmitry Goncharov)
Pull request description:
This reduces the amount of syntax noise in the makefiles.
Setting V=1 still enables verbose logging.
The only noticeable difference in behavior is that, unless V=1 is specified, make won't print its own messages like
make: Nothing to be done for 'all', make: 'all' is up to date, or touch <file>, if -t is specified.
ACKs for top commit:
laanwj:
Tested ACK 8494dcae0e32716fd7cc7abeacf0a795a1303e6a
Tree-SHA512: 66b9111229995aa54a9e87f4571648727d89b8529caec651063cdfe5c00a64341371b648701d192b2334df0614617a00c28eaa56c7f08ee9c00127cada0293ab
|
|
66a20a54a2a8446e6257b872a161089e0eed1688 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 (50c502f54abd9eb15c8ddca013f0fdfae3d132a9), 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 66a20a54a2a8446e6257b872a161089e0eed1688
Tree-SHA512: 211f794de2fc569f0ade2a4da805b8bfd4ce2ab0930c5d427acc4f5d015fcdc4911f02fc64f6401197f7641aed79944a9594be80c817547be3269cdd721cf79b
|
|
This approach is safer as it allows the configure script to check the
availability of a compiler flag.
|
|
Since Qt 5.14.0 the CROSS_COMPILE variable always being overridden by
the Qt build system internally.
See upstream commit: c28b881c98fadcd3415370fad2525b558f6b03e4
|
|
|
|
This change fixes some weirdness like `make print-capnp_version` output
in depends.
|
|
macOS
19f3896c9a6a710bdd49b65a4a4947d90eb8a692 build: Fix x86_64 <-> arm64 cross-compiling for macOS (Hennadii Stepanov)
Pull request description:
Currently, on master (111c3e06b35b7867f2e0f740e988f648ac6c325d), dependencies are built for the build system architecture, not the provided host.
On Intel-based macOS Big Sur 11.6.1 (20G224):
```
% make -C depends HOST=arm64-apple-darwin20
% lipo -info depends/arm64-apple-darwin20/lib/libsqlite3.a
Non-fat file: depends/arm64-apple-darwin20/lib/libsqlite3.a is architecture: x86_64
```
On M1-based macOS Monterey 12.0.1 (21A559) the `boost` package building fails with multiple errors like that:
```
% make -C depends boost HOST=x86_64-apple-darwin19
...
error: option 'cf-protection=return' cannot be specified on this target
error: option 'cf-protection=branch' cannot be specified on this target
2 errors generated.
```
This PR allows to cross-compile as follows:
- on Intel-based macOS Big Sur 11.6.1 (20G224):
```
% make -C depends HOST=arm64-apple-darwin20
% lipo -info depends/arm64-apple-darwin20/lib/libsqlite3.a
Non-fat file: depends/arm64-apple-darwin20/lib/libsqlite3.a is architecture: arm64
% CONFIG_SITE=$PWD/depends/arm64-apple-darwin20/share/config.site ./configure
% make
% lipo -info src/qt/bitcoin-qt
Non-fat file: src/qt/bitcoin-qt is architecture: arm64
```
- on M1-based macOS Monterey 12.0.1 (21A559):
```
% make -C depends HOST=x86_64-apple-darwin19
% CONFIG_SITE=$PWD/depends/x86_64-apple-darwin19/share/config.site ./configure
% make
% lipo -info src/qt/bitcoin-qt
Non-fat file: src/qt/bitcoin-qt is architecture: x86_64
```
No behavior change for other builder-host pairs.
This is an alternative to bitcoin/bitcoin#22506.
ACKs for top commit:
fanquake:
ACK 19f3896c9a6a710bdd49b65a4a4947d90eb8a692 - this is definitely cleaner than the approach in #22506. I've tested the x86_64 -> arm64 and arm64 -> x86_64 cross-compiles. Going to go-ahead and merge this given it's scoped to building for darwin targets, on darwin. Not sure if this is something we'll actually see used very often.
Tree-SHA512: 67a7fed1db79bc43d41aabb5a676f90417a879e5dcffec1384c288b56ee32ba06ae3819abdc7aca85b81af6e782bcfff5c83a67a455560249fa095a807fc1187
|
|
6575d354c8176c67c847b0e0a6cdd42800731a00 build: Bump Fonconfig version up to 2.12.6 (Hennadii Stepanov)
Pull request description:
This PR gets rid of `remove_char_width_usage.patch`.
Some additional observations:
1. Newer Fontconfig versions (2.13.0 and 2.13.1) introduce a new dependency, `uuid`, in the [`7b48fd3dd406b926f0e5240b211f72197ed538a9`](https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/7b48fd3dd406b926f0e5240b211f72197ed538a9) commit
2. In Fonconfig 2.13.1 (the current stable) excludes the `fcobjshash.h` from the distributive archive (see [`31269e3589e0e6432d12f55db316f4c720a090b5`](https://gitlab.freedesktop.org/fontconfig/fontconfig/-/commit/31269e3589e0e6432d12f55db316f4c720a090b5)), that makes our `gperf_header_regen.patch` unusable, and requires `gperf` as a dependency.
ACKs for top commit:
fanquake:
ACK 6575d354c8176c67c847b0e0a6cdd42800731a00 - from the best I can determine this doesn't have any versioning / ABI implications. The ABI difference between 2.12.1 and 2.12.6 is two symbol additions, neither of which are used by Qt. Fontconfig seems to be better at maintaining backwards compatibility compared to a library like Freetype.
Tree-SHA512: 36780a0c5a658469697e524d682ebab56c320cb04f8297bc215f4552f183d4f560501fb0a869982fd9053d4a2d571c7fd971d8f5e96c9da9a9d142c485e3baa4
|
|
maintainability
2f356a0ca8b080c860c8924d201b98f1f9fa0ad5 scripted-diff: Drop Darwin version for better maintainability (Hennadii Stepanov)
Pull request description:
After this PR, any macOS tools version bumping in the future will touch fewer files in the repo.
Pointing a Darwin version for the `--host` system does not matter for the following reasons:
- in terms of the resulted binaries, we should only care about the minimum supported macOS version which is a separated parameter in our build system.
- in terms of the build system itself, the usage of the `$(host)` variable is self-consistent enough. Btw `$(host_os)` value already has the version dropped:
```
$ make -C depends --no-print-directory print-host_os HOST=x86_64-apple-darwin19
host_os=darwin
```
ACKs for top commit:
gruve-p:
ACK https://github.com/bitcoin/bitcoin/pull/23585/commits/2f356a0ca8b080c860c8924d201b98f1f9fa0ad5
promag:
ACK 2f356a0ca8b080c860c8924d201b98f1f9fa0ad5.
fanquake:
ACK 2f356a0ca8b080c860c8924d201b98f1f9fa0ad5
Tree-SHA512: 374896ab0ba02b0d8b4b21431fe963bd213b0d09586e0898c13a4c5fa294c1b693f1b2c92880c245c4157c14217b4825b36522f461930477f4d2a727086ebb2a
|
|
ac9e4bc1e27374671ff1ebd96b939793f784ccb2 build: Fix build for Android x86_64 (Hennadii Stepanov)
Pull request description:
bitcoin/bitcoin#23489 [introduced](https://github.com/bitcoin/bitcoin/pull/23489#issuecomment-985457915) a regression making build for `HOST=x86_64-linux-android` broken due to the [QTBUG-86785](https://bugreports.qt.io/browse/QTBUG-86785).
This PR fixes this regression.
ACKs for top commit:
fanquake:
ACK ac9e4bc1e27374671ff1ebd96b939793f784ccb2
Tree-SHA512: c841a56d745c4b4a75e1bc4d89752de153aa6328752a8fd7df614363ed046a291a9eb58605d82fcba21f3c8b0f0bf47786ed0a63c29f81f5d4ad9c0b12304100
|
|
78a6bc6919e96b5c32efd370540a28aecc2262f6 build, qt: Use Android NDK r23 LTS (Hennadii Stepanov)
Pull request description:
This is a continuation of bitcoin/bitcoin#23478, and, thanks to bitcoin/bitcoin#23489, a oneline patch is only required to be able build the `qt` package in depends with Android NDK r23 LTS.
ACKs for top commit:
fanquake:
ACK 78a6bc6919e96b5c32efd370540a28aecc2262f6
Tree-SHA512: 09c6e8739ecbcbf5fdd6c2103577be2676eb448941f97c781f476918056c8405d2531d5cef8f240e4d1205c2d49f879edbba74dd5e77799a887b76a5c76ebe5b
|
|
|
|
|
|
|
|
Very old shells suffered from bugs which meant that prefixing variables
with an "x" to ensure that the lefthand side of a comparison always
started with an alphanumeric character was needed. Modern shells don't
suffer from this issue (i.e Bash was fixed in 1996).
In any case, we've already got unprefixed checks used in our codebase,
i.e https://github.com/bitcoin/bitcoin/blob/master/configure.ac#L292,
and have dependencies (in depends) that also use unprefixed comparisons.
I think it's time that we can consolidate on not using the x-prefix
workaround. At best it's mostly just confusing.
More info:
https://github.com/koalaman/shellcheck/wiki/SC2268
https://www.vidarholen.net/contents/blog/?p=1035
|
|
|
|
|
|
Required for xcb_icccm.
|
|
|
|
|
|
|
|
|
|
Minimum required libxcb to build qt 5.15.x is 1.11.
https://codereview.qt.nokia.com/c/qt/qtbase/+/253905
Some plugins have been re-enabled as they are required by Qt.
|
|
Co-authored-by: mammix2 <mammix2@hotmail.com>
|
|
|
|
|
|
|
|
|
|
855bd7550368f9dc64eaed85fe0a345b83f01613 build, qt: Ditch `no_sdk_version_check.patch` (Hennadii Stepanov)
Pull request description:
Since Qt 5.12.2 (see https://github.com/qt/qtbase/commit/5d181961ea28da07128384aa5144c67d07f87a3e) it is possible to control whether to check macOS SDK with the `QT_MAC_SDK_NO_VERSION_CHECK` variable.
ACKs for top commit:
fanquake:
ACK 855bd7550368f9dc64eaed85fe0a345b83f01613
Tree-SHA512: e490f22da9c37d25b58418ca62e65d2303cfbd83139f4abea4b67c37fa97e9a882ccc9d484b49cd2bb3a8851ea35e63123d3c6db7f804d6b50f41b10bd10c10b
|
|
|
|
|
|
|
|
This should have been a part of dropping macports support in #15175.
|
|
This reverts commit cdb41d5573b1e2ed1bc1d8d1dc9f77e82672ee1f.
It is no longer required because of the previous commit.
|
|
|
|
This change fixes qt build on M1 Apple Silicon
|
|
-BEGIN VERIFY SCRIPT-
sed -i 's/darwin19/darwin/g' $(git grep --files-with-matches 'darwin19')
-END VERIFY SCRIPT-
|