mold links non-viable Rust binaries on bcachefs

Issue

When installing fd-find (smallest crate I could reliably reproduce this on), rustic-rs, broot, jj-cli, ripgrep, bacon or presenterm, trying to run the resulting binary results in an error. The specific error seems to alternate randomly betweeen 3 different ones.

This only happens with both the mold linker and a global target dir set in .cargo/config.toml (entire contents):

[build]
rustflags = [
  "-Clinker=clang",
  "-Clink-arg=-fuse-ld=/usr/bin/mold",
]
target-dir = "/home/user/.cache/cargo/target/"

It also doesn't occur on all binaries, for example atem-dots and uwuify work fine.
All the below errors occur on both the stable and nightly compiler

Zeroed header

$ cargo install <crate>
$ <binary>
bash: <binary>: cannot execute binary file: Exec format error

Here one, but maybe not the entire, issue is, that the headers of the binaries are for some reason completely zeroed:

$ hexdump -n 16 -C <binary>
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010

Zeroed verneed

$ cargo install <crate>
$ <binary>
<binary>: error while loading shared libraries: <binary>: unsupported version 0 of Verneed record

Here, the binaries do contain a valid ELF header:

$ hexdump -n 16 -C <binary>
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010

Instead, the version‑need section is completely zeroed:

$ readelf -x .gnu.version_r ./fd


Hex dump of section '.gnu.version_r':
  0x00001c18 00000000 00000000 00000000 00000000 ................
  0x00001c28 00000000 00000000 00000000 00000000 ................
  0x00001c38 00000000 00000000 00000000 00000000 ................
  0x00001c48 00000000 00000000 00000000 00000000 ................
  0x00001c58 00000000 00000000 00000000 00000000 ................
  0x00001c68 00000000 00000000 00000000 00000000 ................
  0x00001c78 00000000 00000000 00000000 00000000 ................
  0x00001c88 00000000 00000000 00000000 00000000 ................
  0x00001c98 00000000 00000000 00000000 00000000 ................
  0x00001ca8 00000000 00000000 00000000 00000000 ................
  0x00001cb8 00000000 00000000 00000000 00000000 ................
  0x00001cc8 00000000 00000000 00000000 00000000 ................
  0x00001cd8 00000000 00000000 00000000 00000000 ................
  0x00001ce8 00000000 00000000 00000000 00000000 ................
  0x00001cf8 00000000 00000000 00000000 00000000 ................
  0x00001d08 00000000 00000000 00000000 00000000 ................
  0x00001d18 00000000 00000000 00000000 00000000 ................
  0x00001d28 00000000 00000000 00000000 00000000 ................
  0x00001d38 00000000 00000000 00000000 00000000 ................
  0x00001d48 00000000 00000000 00000000 00000000 ................
  0x00001d58 00000000 00000000 00000000 00000000 ................
  0x00001d68 00000000 00000000 00000000 00000000 ................
  0x00001d78 00000000 00000000 00000000 00000000 ................
  0x00001d88 00000000 00000000 00000000 00000000 ................

SIGSEGV

This one is the hardest to reproduce and only happened once during my testing and I sadly wasn't able to capture a lot of details, but the binary instantly crashed with a SIGSEGV

Meta

rustc +nightly --version --verbose:

rustc 1.90.0-nightly (da58c0513 2025-07-03)
binary: rustc
commit-hash: da58c051315268a197ce280f6ba07bbd03c66535
commit-date: 2025-07-03
host: x86_64-unknown-linux-gnu
release: 1.90.0-nightly
LLVM version: 20.1.7

rustc +stable --version --verbose:

rustc 1.88.0 (6b00bc388 2025-06-23)
binary: rustc
commit-hash: 6b00bc3880198600130e1cf62b8f8a93494488cc
commit-date: 2025-06-23
host: x86_64-unknown-linux-gnu
release: 1.88.0
LLVM version: 20.1.5

mold --version --verbose

mold 2.40.1 (96c798d7be595d833f3f7d33ca32fd43f2731b89; compatible with GNU ld)

I feel like I still don't really have a grasp on the real issue, if there is something, please let me know what I can try to narrow it down.

Reproduce with cargo install using the shown .cargo/config.toml, the mold linker, and a global target directory, then inspect the resulting binaries with hexdump and readelf. Compare the listed crates and working examples while narrowing whether the failure depends on mold, the shared target directory, or bcachefs; done means identifying a reproducible cause and confirming binaries are valid and executable.