-crt-static on musl links with libgcc_s

[nitsky]

Hi, I am building dynamic libraries that I call from scripting languages (elixir nif, nodejs native addon, etc) on Alpine Linux. I have been successful using the x86_64-unknown-linux-musl target with -C target-feature=-crt-static to enable building cdylibs. However, I find that any cdylib produced this way links dynamically not only to musl but also to libgcc_s:

$ ldd target/release/libhello.so
/lib/ld-musl-x86_64.so.1 (0x7ffa2d2fb000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7ffa2d1cd000)
libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x7ffa2d2fb000)

Unfortunately, the Alpine Linux docker image does not include the libgcc package by default, and the packages for most scripting languages do not depend on it, so users of my library will be required to explicitly install it, which is an inconvenience.

Below is the line in the unwind crate that dynamically links to libgcc_s on musl targets when crt-static is disabled:

rust/library/unwind/src/lib.rs

Line 41 in b36f770

#[link(name = "gcc_s", cfg(not(target_feature = "crt-static")))]

Is there a path to compiling cdylibs for musl without dynamically linking to libgcc_s? Perhaps while unwinding across FFI boundaries remains undefined behavior, -crt-static on musl could statically link the unwind functionality like it does with +crt-static?

Related issues:
#29527
#55120

rustc --version --verbose:

rustc 1.50.0 (cb75ad5db 2021-02-10)
binary: rustc
commit-hash: cb75ad5db02783e8b0222fee363c5f63f7e2cf5b
commit-date: 2021-02-10
host: x86_64-unknown-linux-musl
release: 1.50.0

[nitsky]

Dynamically linking libgcc_s with -crt-static also causes an error cross-compiling a cdylib from gnu linux to musl. I tried the following both on arch linux and in an ubuntu docker container with musl-gcc installed:

RUSTFLAGS="-C linker=musl-gcc -C target-feature=-crt-static" cargo build --release --target x86_64-unknown-linux-musl

error: linking with `musl-gcc` failed: exit code: 1
  = note: /usr/bin/ld: cannot find libgcc_s.so.1
          collect2: error: ld returned 1 exit status

[rylev]

I've also run into this issue as well when compiling for an environment which uses musllibc as the libc implementation. Unfortunately, the environment is not under my direct control so installing libgcc is not possible meaning there's no workaround as far as I can tell.

[Logarithmus]

Why can't use just do apk add libgcc or xbps-install libgcc?

[wader]

@Logarithmus In my case I want to produce a binary that will run in many different docker base images. Having a binary with no external dependencies makes that very convenient. Installing libgcc requires that the base image is a distro with a package manger and has a libgcc package that is compatible. One could of course distribute the alpine libgcc somehow but that is less convenient.

[dupu222]

is there a way dont't to link libgcc_s when building dynamic lib on musl -crt-static?
is there a way to static link libunwind in this case?

[wader]

@dupu222 Maybe these alpine issues are interesting for you. The gcc_s issue should be fixed in alpine edge built rust toolchain (package version 1.62.1 or laster):
https://gitlab.alpinelinux.org/alpine/aports/-/issues/11806
https://gitlab.alpinelinux.org/alpine/aports/-/issues/12941