Builds on musl targetiing musl are linked to glibc

[WhyNotHugo]

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 

Any reference to xkbcommon-rs results in the binary being linked to glibc and becoming unusable on this platform. However, looking at xkbcommon-rs, I see no references to glibc, so it's not immediately clear to me what's wrong. OTOH, I'm also not sure how this crate does find and link C-xkbcommon.

Trying to write code that references the C library itself fails to build for me. E.g.: the following fails to build due to not finding C-xkbcommon:

#[link(name = "xkbcommon")]
extern "C" {
    fn xkb_context_new(flags: u32) -> *mut ();
}

fn main() {
    unsafe { xkb_context_new(0); }
}

Again, I don't quite see anything in particular in this repo that addresses this, so I'm kinda missing how the whole thing builds -- which should definitely help figure how why the wrong libc gets linked.

I tried asking in Rust's Zulip chat, but haven't managed to pinpoint what the issue might be. https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Building.20on.20musl.20with.20target.20musl.20links.20to.20glibc

Do you have any idea what might be up?

[WhyNotHugo]

Oddly, I can't repro this on x86_64-unknown-linux-musl.

[rtbo]

I suggest that you should open an issue in Cargo.
This crate only specifies that symbols are to be linked with xkbcommon, but cargo does the actual job.

[WhyNotHugo]

Yeah, I figured this is an upstream issue somewhere. Using rustup yields the bogus results described above. Using packages from alpine/edge on that same host yield sane builds.

[WhyNotHugo]

I've reported this with rustup (rust-lang/rust#108878) since the issue seems to with the binaries provided there.

Sorry for the noise.