build: avoid embedding depends paths in build RPATH #36053

After PR #33247 removed CMAKE_SKIP_BUILD_RPATH from the CMake build system as part of changes related to Guix binary checks, Linux builds using the depends toolchain could embed the absolute depends/<host>/lib path in build-tree binaries.

One user-visible consequence was incorrect font rendering in the Bitcoin Core Qt GUI. Instead of rendering the bundled RobotoMono-Bold.ttf font as intended, the GUI could fall back to a system-provided font and sizing, resulting in text that was unpleasant to read and, in some cases, difficult to read.

This PR restores build-RPATH suppression specifically for the depends toolchain, without reverting the broader changes from #33247 or affecting Guix builds. It also prevents Linux binaries built with depends from containing the absolute depends library path in their RPATH/RUNPATH.

Tested on Linux x86_64 with depends builds on v31.1 and current master. After this change, bitcoin-qt, bitcoin-gui, and test_bitcoin-qt contain no RPATH/RUNPATH, and their generated link commands contain no -Wl,-rpath.

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--006a51241073e994b41acfe9ec718e94-->

Code Coverage & Benchmarks

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

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline and AI policy for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

The CI fails:

215/376 Test [#222](/github-metadata-backup-bitcoin-bitcoin/222/): test_kernel ................................................................***Failed    0.00 sec
/home/runner/work/_temp/build_ ₿🧪_/bin/test_kernel: error while loading shared libraries: libbitcoinkernel.so: cannot open shared object file: No such file or directory

<!--85328a0da195eb286784d51f73fa0af9-->

🚧 At least one of the CI tasks failed. _{Task previous releases: https://github.com/bitcoin/bitcoin/actions/runs/32494130769/job/97015366408} _{LLM reason (✨ experimental): CI failed because CTest test_kernel crashed due to a missing shared library: libbitcoinkernel.so: cannot open shared object file.}

<details><summary>Hints</summary>

Try to run the tests locally, according to the documentation. However, a CI failure may still happen due to a number of reasons, for example:

• Possibly due to a silent merge conflict (the changes in this pull request being incompatible with the current code in the target branch). If so, make sure to rebase on the latest commit of the target branch.

• A sanitizer issue, which can only be found by compiling with the sanitizer and running the affected test.

• An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

</details>

Amended the PR to affect only the Qt targets built against the local depends toolchain, instead of applying SKIP_BUILD_RPATH globally. The build RPATH required by test_kernel is preserved, and the previously failing tests now pass CI.

One user-visible consequence was incorrect font rendering in the Bitcoin Core Qt GUI. Instead of rendering the bundled RobotoMono-Bold.ttf font as intended, the GUI could fall back to a system-provided font and sizing, resulting in text that was unpleasant to read and, in some cases, difficult to read.

The embedded RobotoMono-Bold.ttf font seems to be working fine in the latest release v31.1: <img width="1222" height="1054" alt="image" src="https://github.com/user-attachments/assets/2336303c-b9b3-4f43-aef1-d1b5e849526f" />

Could you please provide more details about the affected system: OS, desktop environment, display server, etc?

The affected system: Linux Mint 22.1 6.8.0-85 Generic kernel XFCE Desktop Environment X11 Display Server

The font issue doesn't present itself on this system when the official 31.1 Release binary is used, it only presents when 31.1 is built locally from source using the depends toolchain.

This build was built from bitcoin-31.1.tar.gz, linked against depends, within the last hour:

readelf -d ./bitcoin-qt | grep -E 'RPATH|RUNPATH' 0x000000000000001d (RUNPATH) Library runpath: [/home/<user>/.../depends/x86_64-pc-linux-gnu/lib:]

<img width="1402" height="975" alt="31 1 dependsbuild" src="https://github.com/user-attachments/assets/bc4037a7-be03-4568-a13c-f9bc28c55689" />

For comparison, I just rebuilt the same source code with the current version of the PR applied and no other changes.

$ readelf -d ./bitcoin-qt | grep -E 'RPATH|RUNPATH' now returns no output, as intended by this PR and, as I understand it, consistent with the intent of PR #33470.

The screenshot below is from that patched v31.1 depends build.

<img width="1406" height="970" alt="31 1 dependsbuild-patched" src="https://github.com/user-attachments/assets/a14cb192-be63-4adf-a087-4db28c03dd57" />

When running a statically-linked bitcoin-qt directly from the build tree, the libfontconfig.so.1 shared library resolves to the one built in depends, which in turn attempts to locate its default configuration file in the same prefix within depends and fails:

Fontconfig error: Cannot load default config file

This does not happen when bitcoin-qt is installed via the cmake --install command.

As a workaround, the FONTCONFIG_PATH environment variable can be used. For example:

$ FONTCONFIG_PATH=/etc/fonts ./build/bin/bitcoin-qt

I reproduced your result locally. Using cmake --install produces exactly the behavior you described. I have no argument with that and appreciate you pointing it out.

My understanding of the workflow had been: build using the depends toolchain, strip the resulting binary to ~29.8 MB, place it wherever on the system the user wants, and essentially “double-click the icon and go,” without cmake --install being a required additional step to achieve correct Qt GUI behavior.

My understanding of the workflow had been: build using the depends toolchain, strip the resulting binary to ~29.8 MB, place it wherever on the system the user wants...

This is exactly what the CMake workflow provides:

$ gmake -C depends -j $(nproc)
$ cmake -B build --toolchain depends/x86_64-pc-linux-gnu/toolchain.cmake
$ cmake --build build
$ cmake --install build --strip --prefix <wherever-on-the-system-the-user-wants>

Approach NACK. Passing around a depends built variable is the kind of entangling that we have previously worked towards avoiding. The current behaviour also seems find to me and not something worth fixing.

Closing for now. Looks like this is controversial, or more an issue/user-question. Possibly an issue can be opened or the docs can be updated, if there is need to?