Builds on *-unknown-linux-musl that link to C libaries produce broken binaries

[WhyNotHugo]

Problem

I'm trying to build the following minimal example:

fn main() {
    _ = xkbcommon::xkb::Context::new(0);
    println!("Hello, world!");
}

I'm buildling on aarch64-unknown-linux-musl, and my target is aarch64-unknown-linux-musl (e.g.: there's no cross-compiling going on here).

The above builds fine, but the resulting binary fails to run:

> cargo run  
   Compiling libc v0.2.137
   Compiling memmap2 v0.5.7
   Compiling xkbcommon v0.5.0
   Compiling hello v0.1.0 (/home/user/hello)
    Finished dev [unoptimized + debuginfo] target(s) in 6.67s
     Running `target/debug/hello`
error: could not execute process `target/debug/hello` (never executed)

Caused by:
  No such file or directory (os error 2)

The resulting binary is clearly linked against glibc, which is not present here:

> ldd target/debug/hello
	/lib/ld-linux-aarch64.so.1 (0xffffacf0b000)
	libxkbcommon.so.0 => /usr/lib/libxkbcommon.so.0 (0xffffacebc000)
	libc.musl-aarch64.so.1 => /lib/ld-linux-aarch64.so.1 (0xffffacf0b000)
> readelf -l target/debug/hello

Elf file type is EXEC (Executable file)
Entry point 0x405328
There are 9 program headers, starting at offset 64

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R      0x8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x000000000000001b 0x000000000000001b  R      0x1
      [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x00000000000581dc 0x00000000000581dc  R E    0x10000
  LOAD           0x0000000000058e28 0x0000000000468e28 0x0000000000468e28
                 0x0000000000007338 0x0000000000008e40  RW     0x10000
  DYNAMIC        0x000000000005fcb0 0x000000000046fcb0 0x000000000046fcb0
                 0x00000000000001f0 0x00000000000001f0  RW     0x8
  TLS            0x000000000005d758 0x000000000046d758 0x000000000046d758
                 0x0000000000000028 0x0000000000000050  R      0x8
  GNU_EH_FRAME   0x0000000000056124 0x0000000000456124 0x0000000000456124
                 0x000000000000132c 0x000000000000132c  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x0000000000058e28 0x0000000000468e28 0x0000000000468e28
                 0x00000000000071d8 0x00000000000071d8  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00     
   01     .interp 
   02     .interp .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .debug_gdb_scripts .eh_frame_hdr .gcc_except_table 
   03     .eh_frame .tdata .init_array .fini_array .data.rel.ro .dynamic .got .data .bss 
   04     .dynamic 
   05     .tdata .tbss 
   06     .eh_frame_hdr 
   07     
   08     .eh_frame .tdata .init_array .fini_array .data.rel.ro .dynamic .got 

Steps

rustup default nightly
mkdir lalala
cd lalala
cargo init
cargo add xkbcommon
cat > src/main.rs <<EOF
fn main() {
    _ = xkbcommon::xkb::Context::new(0);
    println!("Hello, world!");
}
EOF
cargo run

Possible Solution(s)

Not sure, I think there's something wrong with the binaries that rustup ships.

Notes

Using cargo/rust/etc from Alpine repositories works fine. It's the binaries pulled by rustup that are faulty somehow.

Originally reported at the library I was trying to use (rust-x-bindings/xkbcommon-rs#37), but eventually realised it seems to be an issue with the binaries that rustup pulls.

Rustup version

rustup 1.25.1 :: v20220715+1493 (394daf022 2022-08-03) dirty 2 modifications
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: The currently active `rustc` version is `rustc 1.65.0 (897e37553 2022-11-02)`

Installed toolchains

Default host: aarch64-unknown-linux-musl
rustup home:  /home/user/.rustup

stable-aarch64-unknown-linux-musl (default)
rustc 1.65.0 (897e37553 2022-11-02)

[WhyNotHugo]

Edit: updated reproduction steps to make them copy-pasteable

[WhyNotHugo]

Updating title since I've now reproduced this on amd64 as wel.

[rbtcollins]

This should be moved to the rust repository I think; rustup isn't involved in the construction of the binaries in the distribution packages

[WhyNotHugo]

There's a likely explanation and some more thorough research on this bug in the downstream issue tracker.

[rbtcollins]

Ok, so the summary is mixed static-and-dylib linking on musl without the static-crt option The link from @WhyNotHugo has more details