Binaries fail to link on musl #144729
Description
Linking a dynamic library on my musl system (Alpine Linux) using rustup's rust and cargo fails.
Minimal reproducible example:
# Cargo.toml
[package]
name = "p"
version = "0.1.0"
edition = "2024"
build = "build.rs"
[dependencies]
lapack-sys = "0.15.0"// build.rs
fn main() {
println!("cargo::rustc-link-lib=dylib=lapack");
}// src/lib.rs
use std::ffi::{c_char, c_int};
pub fn dsyev() {
let jobz = 'V' as c_char;
let uplo = b'U' as c_char;
let n = 4 as c_int;
let mut a = vec![0.0; 16];
let lda = n;
let mut w = vec![0.0; 16];
let mut work = vec![0.0; 16];
let lwork = 16 as c_int;
let mut info: i32 = 0;
unsafe {
lapack_sys::dsyev_(&jobz, &uplo, &n, a.as_mut_ptr(), &lda, w.as_mut_ptr(), work.as_mut_ptr(), &lwork, &mut info)
}
}
#[cfg(test)]
mod test {
#[test]
fn t() {
// SIGSEGV because the address of `dsyev_` is NULL
super::dsyev();
}
}I expected the tests to run. Instead, it fails with a sigsegv:
/tmp/p> cargo test
Compiling p v0.1.0 (/tmp/p)
Finished `test` profile [unoptimized + debuginfo] target(s) in 0.22s
Running unittests src/lib.rs (target/debug/deps/p-c1814fa57c0b733d)
running 1 test
error: test failed, to rerun pass `--lib`
Caused by:
process didn't exit successfully: `/tmp/p/target/debug/deps/p-c1814fa57c0b733d` (signal: 11, SIGSEGV: invalid memory reference)dsyev_ is undefined in objdump:
/tmp/p> objdump -T ./target/debug/deps/p-c1814fa57c0b733d
./target/debug/deps/p-c1814fa57c0b733d: file format elf64-x86-64
DYNAMIC SYMBOL TABLE:
0000000000000000 w DF *UND* 0000000000000000 getrandom
0000000000000000 DF *UND* 0000000000000000 dsyev_
00000000000ba76d g DF .text 000000000000000a posix_spawnattr_init
00000000000a4410 g DF .text 0000000000000097 _Unwind_Resume_or_Rethrow
...But it desn't get linked, despite the fact that the binary depends on liblapack:
/tmp/p> ldd ./target/debug/deps/p-c1814fa57c0b733d
/lib/ld-musl-x86_64.so.1 (0x7f78dca19000)
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x7f78dba00000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x7f78db943000)
libgfortran.so.5 => /usr/lib/libgfortran.so.5 (0x7f78db400000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f78dc8da000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7f78dca19000)
libquadmath.so.0 => /usr/lib/../lib/libquadmath.so.0 (0x7f78dc891000)Meta
rustc --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-musl
release: 1.88.0
LLVM version: 20.1.5
Backtrace fails because it's a segmentation fault, but I checked with gdb, it's dsyev_ being called despite being a null pointer.
Alpine's own distributed version of rust works correctly.