[wip] A more static bitcoin-qt #33537

1. 
   fanquake commented at 0:39 am on October 4, 2025: member

   Based on #33181. Still some issues making libcxb fully static. Untested.
2. guix: move static-libc++ into CMAKE_EXE_LINKER_FLAGS flags

   Make it clearer that we are only applying this to executables.

   1dd45a452b
3. guix: build for Linux HOSTS with -static-libgcc 7c95517596
4. depends: static libxcb-render-util a24a1d957d
5. depends: static libxcb-keysyms d6d973a61f
6. depends: static libxcb-util-wm 6606e5406b
7. depends: static libxkbcommon c96bf13825
8. depends: libXau 1.0.12 cf49b14d55
9. depends: libxcb-util 0.4.1 18991964bd
10. depends: libxcb-util-image 0.4.1 9673f17183
11. depends: libxcb-util-keysyms 0.4.1 7bbe48b597
12. depends: libxcb-util-renderutil 0.3.10 93b2c800a4
13. depends: libxcb-util-wm 0.4.2 198e46ca89
14. depends: static libxcb-util-image a0f2315cff
15. f: maybe squash into last 0e4049591a
16. 
    DrahtBot commented at 0:39 am on October 4, 2025: contributor

    The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

    Code Coverage & Benchmarks

    For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33537.

    Reviews

    See the guideline for information on the review process. A summary of reviews will appear here.

    Conflicts

    Reviewers, this pull request conflicts with the following ones:

    • #33181 (guix: build for Linux HOSTS with -static-libgcc by fanquake)
    • #25573 ([POC] guix: produce a fully -static-pie bitcoind by fanquake)
    • #24123 (guix: Pointer Authentication and Branch Target Identification for aarch64 Linux by fanquake)

    If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

17. 
    hebasto commented at 7:48 am on October 4, 2025: member

    How is this approach better than #29923?

    cc @laanwj

18. 
    fanquake commented at 9:42 am on October 8, 2025: member

    How is this approach better than #29923?

    They are doing different things. This PR produces a (much more) static bitcoin-qt, using depends as is. #29923 introduces new tooling, to essentially “hide” the runtime loading, the binary is not any more static.

19. 
    hebasto commented at 11:26 am on October 8, 2025: member

    How is this approach better than #29923?

    They are doing different things. This PR produces a (much more) static bitcoin-qt, using depends as is. #29923 introduces new tooling, to essentially “hide” the runtime loading, the binary is not any more static.

    Sure. But #29923 also reduces build dependencies. Isn’t that one of the goals of build system design?

20. 
    fanquake commented at 11:41 am on October 8, 2025: member

    But #29923 also reduces build dependencies.

    I’m not sure it reduces them; they are just moved into a different repository? That repository will need ongoing maintenance, the deps (headers) copied into there, as well as a fake libc, still need updating (I’m assuming syncronised with the Qt we are shipping in this repo, so changes needed there could also block changes here), as well as maintaining the new tooling that actually generates the wrappers. It also looks like the scope / number of dependencies would also increase over time https://github.com/laanwj/qtsowrap/issues/7 ?

21. 
    purpleKarrot commented at 4:10 pm on October 9, 2025: contributor

    @fanquake, what is the motivation for a statically built bitcoin-qt? Is the performance or the package size a concern? Or is it to simplify deployment, like being able to provide a single binary that can be run on any Linux machine? If the latter is the case, AppImage might be an alternative approach. CMake version 4.2 introduces a CPack AppImage Generator.
22. 
    fanquake commented at 10:21 am on October 15, 2025: member

    Or is it to simplify deployment, like being able to provide a single binary that can be run on any Linux machine?

    We currently provide a single binary that can be run on (most) Linux machines (along with anything in https://github.com/bitcoin-core/packaging); however I’d like to remove runtime requirements further. See #33434 for a recent motivation (users shouldn’t need to install additional dependencies/install other software to run our software).

    If the latter is the case, AppImage might be an alternative approach.

    Reading the CMake docs, it’s not clear that AppImage gains us much? We still have to produce a binary meeting our requirements and bundle any relevant dependencies i.e from https://cmake.org/cmake/help/git-master/cpack_gen/appimage.html:

    The appimagetool does not scan for libraries dependencies it only packs the installed content and check if the provided .desktop file was properly created. For best compatibility it’s recommended to choose some old LTS distro and built it there, as well as including most dependencies on the generated file.

    So it seems that even if we were going to use AppImage, we’d still want to simplify our binaries as much as possible.

Contributors
fanquake DrahtBot hebasto purpleKarrot