rustc SIGSEGVs when running proc-macro on musl host with link-self-contained=yes

[kayabaNerve]

The following Dockerfile fails to build, with rustc experiencing a SIGSEGV.

FROM rust:1.91.1-alpine
 
WORKDIR /mre
 
ENV RUSTFLAGS="-Clink-self-contained=yes"
RUN cargo init
RUN cargo add --build rustversion
RUN echo 'fn main() { if rustversion::cfg!(nightly) {} }' > ./build.rs
RUN cargo build

> docker build -f Dockerfile .
[+] Building 10.5s (9/9) FINISHED                                                                                                                                              docker:default
 => [internal] load build definition from Dockerfile                                                                                                                                     0.0s
 => => transferring dockerfile: 256B                                                                                                                                                     0.0s
 => [internal] load metadata for docker.io/library/rust:1.91.1-alpine                                                                                                                    1.8s
 => [internal] load .dockerignore                                                                                                                                                        0.0s
 => => transferring context: 2B                                                                                                                                                          0.0s
 => [1/6] FROM docker.io/library/rust:1.91.1-alpine@sha256:fbcca3e30e26f79986809d5dbfcdbeaaf8d3f8a4475b7a19a973363b45c74d97                                                              0.0s
 => => resolve docker.io/library/rust:1.91.1-alpine@sha256:fbcca3e30e26f79986809d5dbfcdbeaaf8d3f8a4475b7a19a973363b45c74d97                                                              0.0s
 => CACHED [2/6] WORKDIR /mre                                                                                                                                                            0.0s
 => CACHED [3/6] RUN cargo init                                                                                                                                                          0.0s
 => CACHED [4/6] RUN cargo add --build rustversion                                                                                                                                       0.0s
 => CACHED [5/6] RUN echo 'fn main() { if rustversion::cfg!(nightly) {} }' > ./build.rs                                                                                                  0.0s
 => ERROR [6/6] RUN cargo build                                                                                                                                                          8.5s
------                                                                                                                                                                                        
 > [6/6] RUN cargo build:                                                                                                                                                                     
2.084  Downloading crates ...                                                                                                                                                                 
3.075   Downloaded rustversion v1.0.22                                                                                                                                                        
3.256    Compiling rustversion v1.0.22                                                                                                                                                        
7.907    Compiling mre v0.1.0 (/mre)                                                                                                                                                          
8.336 error: could not compile `mre` (build script)
8.336 
8.336 Caused by:
8.336   process didn't exit successfully: `/usr/local/rustup/toolchains/1.91.1-x86_64-unknown-linux-musl/bin/rustc --crate-name build_script_build --edition=2024 build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no --check-cfg 'cfg(docsrs,test)' --check-cfg 'cfg(feature, values())' -C metadata=91288cbb7c6a86c7 -C extra-filename=-5e8e6de0e4e22d63 --out-dir /mre/target/debug/build/mre-5e8e6de0e4e22d63 -C incremental=/mre/target/debug/incremental -L dependency=/mre/target/debug/deps --extern rustversion=/mre/target/debug/deps/librustversion-07ea97a0736ef05d.so -Clink-self-contained=yes` (signal: 11, SIGSEGV: invalid memory reference)
------
Dockerfile:9
--------------------
   7 |     RUN cargo add --build rustversion
   8 |     RUN echo 'fn main() { if rustversion::cfg!(nightly) {} }' > ./build.rs
   9 | >>> RUN cargo build
  10 |     
--------------------
ERROR: failed to build: failed to solve: process "/bin/sh -c cargo build" did not complete successfully: exit code: 101

Presumably, the exact issue is loading a dynamic library (the proc-macro) which has musl linked in to a process (rustc) which already has a libc.

[workingjubilee]

Yes. I don't think there's anything to do here.

[workingjubilee]

Hypothetically, one could argue that we could radically redesign how proc macros work, but that just makes this issue a duplicate with other issues about that because there are already such proposals.

[kayabaNerve]

Well, nothing to do to make this work, but it still shouldn't SIGSEGV and should be rejected as proc-macros are when +crt-static is enabled (at least for musl), right?

EDIT: The bundled libraries do appear to work when libc is presented as a shared object, which a single call to gcc is able to do. Maybe this should work? serai-dex/serai@c45c973 exemplifies using the self-contained libraries as a substitute for libraries provided via the distribution.

[workingjubilee]

Alpine is a dynamically linked musl distro, which significantly confounds what "should" happen here.

[kayabaNerve]

As someone who spent the last few hours attempting to remove musl-dev from a Docker image, I completely agree Alpine + musl + Rust is nothing but a minefield. I'm also (at least on a surface level) aware of various Rust discussions on default behaviors and what's possible given the current proc-macro system.

Given the example of this appearing to work (edited into my above comment, your own reply appearing as I was typing my edit, apologies for the unfortunate timing), it may be worth considering promoting into support behavior instead of disregarding as musl being musl. I'm sure this'll be eligible to be discussed across three separate issues on how to move forward with musl targets however, and don't wish to force such a headache.

[workingjubilee]

that's definitely curious.

does the test case differ in behavior when using a glibc distro instead? you present it as an entire Dockerfile... hm.

[kayabaNerve]

For Alpine Linux, the missing object files/libraries (as discussed ad infinitum w.r.t Rust) are Scrt1.o, crti.o, crtn.o, and libc itself. Rust ships those for its musl targets as intended for use by the link-self-contained feature.

All I did was take the libraries self-contained within Rust and add them to the system's path. The only caveat preventing me from using link-self-contained=yes directly was how link-self-contained=yes always statically links the self-contained libraries, even when target-feature=-crt-static is explicitly set. Dynamic linking is required here since musl cannot be statically-linked into a binary which already has a libc linked (even if another instance of itself). I'm unsure how glibc handles being linked multiple times as it's infrequently statically-linked in the first place, and definitely unsure how Rust vendors it for its self-contained libraries.

---

My project was using a Dockerfile for a reproducible build, hence why the examples I posted were themselves Dockerfile. Thankfully, they work quite well as MREs, especially since most people aren't natively running musl targets.

I originally built from Debian as they offer a historical package server, pinnable to an exact timestamp, to ensure the development environment was constant. I moved to Alpine as it worked and had a smaller footprint. Today's adventure was just about removing the musl-dev package as it was pinned by a version, when I'd prefer everything to be pinned by a hash (and don't wish to publish/maintain derivative images myself). While that's my hyper-specific use-case, the example here is applicable to anyone who wishes to use the self-contained libraries, whose existence has apparently already been justified (as it's stablized).

Installing Rust's libraries to the system was acceptable here because:

• This Linux system executes a single Rust build before outputting an artifact, so I only need Rust (who shipped the libs) to like these libs
• The artifact is a WASM blob which doesn't link libc and isn't directly affected by this
• I've pinned exact hashes, so even if I'm relying on Rust's internals, I won't have breakage overnight

This may be totally idiotic and deserve nothing but hellfire. Support for -crt-static in link-self-contained, at least for the special-case of proc-macros on musl targets, seems worth its own issue to me though? That'd allow this build to work out of the box, which sounds like a better outcome than this being rejected? But it is silly to suggest dynamic linking when building for the case where the system doesn't have the libraries inherently (or it's explicitly desired not to use the system's libraries).

---

EDIT: As one additional thought an hour later, installing to the system is presumably unnecessary for the example compared to simply substituting Rust's libc.a with the created libc.so. That'd at least be more proximate to the idea of using link-self-contained to this end, even though a proper solution would require having both and appropriately selecting one or the other.

[0xdeafbeef]

Also played around with link-self-contained=yes,

found that hello world + miette

builds with

RUSTFLAGS="-C link-self-contained=yes -C panic=abort" cargo build --release --target x86_64-unknown-linux-gnu

and fails with

RUSTFLAGS="-C link-self-contained=yes -C panic=abort" cargo build --release

Compiling proc-macro2 v1.0.103
   Compiling quote v1.0.42
error: failed to run custom build command for `quote v1.0.42`

Caused by:
  process didn't exit successfully: `/home/odm3n/.cargo/build/59/653b71c7c89abe/release/build/quote-0ca7f70367ff4812/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: failed to run custom build command for `proc-macro2 v1.0.103`

Caused by:
  process didn't exit successfully: `/home/odm3n/.cargo/build/59/653b71c7c89abe/release/build/proc-macro2-48badb3343d77ca3/build-script-build` (signal: 11, SIGSEGV: invalid memory reference)

which is strange, given that host is x86_64-unknown-linux-gnu

rustc -vV
rustc 1.91.0 (f8297e351 2025-10-28)
binary: rustc
commit-hash: f8297e351a40c1439a467bbbb6879088047f50b3
commit-date: 2025-10-28
host: x86_64-unknown-linux-gnu
release: 1.91.0
LLVM version: 21.1.2

Not sure if i need to file another bug, seems very related

upd1:

looks like a regression:

RUSTFLAGS="-C link-self-contained=yes -C panic=abort" cargo +1.89.0-x86_64-unknown-linux-gnu build --release
   Compiling proc-macro2 v1.0.103
   Compiling unicode-ident v1.0.22
   Compiling quote v1.0.42
   Compiling cfg-if v1.0.4
   Compiling unicode-width v0.1.14
error: option `-C link-self-contained` is not supported on this target

error: could not compile `quote` (build script) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
error: could not compile `proc-macro2` (build script) due to 1 previous error