Linking glutin statically against musl fails due to libloading

[jean-airoldie]

Bug Description

If i run any example on the master branch in the glutin_examples repo with target "x86_64-unknown-linux-musl", I get a linking error.

$ cargo run --example window --target "x86_64-unknown-linux-musl"

error: linking with `cc` failed: exit status: 1
  |
  = note: LC_ALL="C" PATH="/home/maxence/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown [...] there is a massively long command that I skipped for brevity
  = note: /usr/bin/ld: /home/user/clone/glutin/target/x86_64-unknown-linux-musl/debug/deps/libglutin-c68c87e24b14f69d.rlib(glutin-c68c87e24b14f69d.4uxhq0lvp7qq48lt.rcgu.o): in function `libloading::os::unix::Library::open::{{closure}}':
          /home/user/.cargo/registry/src/index.crates.io-6f17d22bba15001f/libloading-0.8.1/src/os/unix/mod.rs:173: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
          /usr/bin/ld: /home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-musl/lib/self-contained/libc.a(dlerror.lo): in function `__get_tp':
          /build/musl-cross-make/build/local/x86_64-linux-musl/obj_musl/../src_musl/arch/x86_64/pthread_arch.h:4: multiple definition of `dlerror'; /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libdl.a(dlerror.o):(.text+0x0): first defined here
          /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libdl.a(dlopen.o): in function `dlopen':
          (.text+0x5): undefined reference to `__dlopen'
          /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libdl.a(dlclose.o): in function `dlclose':
          (.text+0x1): undefined reference to `__dlclose'
          /usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/10/../../../x86_64-linux-gnu/libdl.a(dlerror.o): in function `dlerror':
          (.text+0x1): undefined reference to `__dlerror'
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

error: could not compile `glutin_examples` (example "window") due to previous error

This isn't specific to the examples, my crate which depends on glutin fails with the same error.

My System

I'm running Debian 11 with kernel version 5.10.0-26-amd64 and all the required packages to build musl. My rust compiler version is `1.76.0-nightly (21cce21d8 2023-12-11).

Speculation

This might be related to this stack overflow post that explains that dlopen should not be statically linked against glibc.

[kchibisov]

That's pretty much intentional, since you generally don't want to statically link video driver and that you can have libs like libglvnd. Different vendors have also different libEGL.so, so we need to dynamically resolve.

Maybe there's a way to use dlopen in fully static executable, but it's up to libloading and not glutin itself.

[jean-airoldie]

From my understanding using dlopen in fully static executable would be possible but unwieldy, to the point it would remove most of the advantages of using a static executable in the first place.

[kchibisov]

I mean, the reason why it's always dynamic is that you don't know what to load, there's no single e.g. libEGL to load, you can have multiple of them, and stuff like libglvnd even has a json based configs when it comes to which vendor to load.