Re: rustc from trixie-backports crashes compiling compiler-builtins

> Am 28. Januar 2026 16:02:49 MEZ schrieb Matthew Gabeler-Lee <[email protected]>:
>>I'm trying to build https://github.com/microsoft/edit using the bpo
>>version of cargo & rustc, and running into a compiler crash:
>>
>>Repro:
>>1. Install rustc, rust-src, and cargo from trixie-backports
>>(1.90.0+dfsg1-1~bpo13+2)
>>2. Clone https://github.com/microsoft/edit
>>3. Build with: RUSTC_BOOTSTRAP=1 cargo build --config
>>.cargo/release.toml --release
>>4. rustc crashes with SIGSEGV
>>
>>The top of the backtrace is:
>>error: rustc interrupted by SIGSEGV, printing backtrace
>>
>>/lib/x86_64-linux-gnu/librustc_driver-1986f22fdc122ac9.so(+0x960ba5)
>>[0x7fe9f0960ba5]
>>/lib/x86_64-linux-gnu/libc.so.6(+0x3fdf0) [0x7fe9efe4adf0]
>>/lib/x86_64-linux-gnu/libLLVM.so.19.1(+0x23b294a) [0x7fe9ea3b294a]
>>/lib/x86_64-linux-gnu/libLLVM.so.19.1(_ZN4llvm16ConstantFoldCallEPKNS_8CallBaseEPNS_8FunctionENS_8ArrayRefIPNS_8ConstantEEEPKNS_17TargetLibraryInfoEb+0x13c)
>>[0x7fe9ea3af6ec]
>>
>>The full crash output is here:
>>https://gist.github.com/fastcat/b41a69b0c171e9a8dacec9b6b5a48837
>>
>>If I use the rust:1.90.0-trixie docker image to do the build, it
>>doesn't crash. Similarly if I use rustc 1.90.1 from a forky docker
>>container, it also doesn't crash. This seems to point to it being
>>something haywire with the BPO build, or perhaps with its
>>dependencies?

I don't know what those docker images contain, so can't tell. If they contain
upstream toolchains, those use a different LLVM build and different Rust
toolchain settings, which might explain the different behaviour/results.

In general RUSTC_BOOTSTRAP is not for public consumption, it is an
escape hatch for building the compiler itself (which uses unstable
features, but needs to be buildable with the stable toolchain).

Similarly, `-Zbuild-std` is not stabilized yet, and a quite big feature at
that.

That being said - `edit` builds fine without `-Zbuild-std` using
trixie-backports. Other crates build fine with `-Zbuild-std`. `edit` sets quite
a few additional options/unstable features (in Cargo.toml and
.cargo/release.toml), it might be that that particular combination is broken on
that particular toolchain (rustc or LLVM or the combination thereof).

Using the 1.91.1 toolchain from forky/sid, the full invocation of

RUSTC_BOOTSTRAP=1 cargo build -Z build-std --config .cargo/release.toml --release

works. the same is true for the (not yet available in the repos) 1.92 build
I've prepared for experimental (with .cargo/release-nightly.toml).

I will upload 1.91.1 to trixie-backports as soon as the LLVM situation is
sorted out. It will upgrade LLVM to 21 (compared to 19 as used by 1.90). If the
issue is caused by LLVM, this might explain the results (upstream "supports" a
range of LLVM versions for each rustc version, but only fully tests things with
the upstream default combination).

>>If there's a way to get symbols for rustc & llvm to get a better
>>backtrace, or other things I can do to get more/better diagnostics,
>>I'm all ears.

Both rustc and llvm come with -dbgsym packages (but they are in a separate part
of the archive):

deb http://deb.debian.org/debian-debug/ trixie-backports-debug main
deb http://deb.debian.org/debian-debug/ trixie-debug main

If you manage to find out more, I'd be happy to take another look. I won't
proactively try to find out more myself, since `edit` is requiring/recommending
things which are outside of the scope of what the stable toolchain is expected
to support, and the next version will likely fix the issue at hand anyway.

Fabian