Cannot build statically linked cargo on musl with RUSTFLAGS="-C target-feature=+crt-static"

[jirutka]

$ RUSTFLAGS="-C target-feature=+crt-static" cargo build --release
error: cannot produce proc-macro for `serde_derive v1.0.36` as the target `x86_64-alpine-linux-musl` does not support these crate types

It does not work since cargo 0.18.0, there were no problem with static build in 0.17.0.

[sanmai-NL]

The issue seems to be fixable in this function. https://sourcegraph.com/github.com/rust-lang/cargo@5a6b69276c050c92a6fa4865a1ca1e989c361431/-/blob/src/cargo/core/compiler/build_context/target_info.rs#L156:12-156:22

[mati865]

It's disabled in Rust: https://github.com/rust-lang/rust/blob/cb6fafbdf3b09da28b09fa7e87a24658d77dd02f/src/librustc_codegen_utils/link.rs#L156

[sanmai-NL]

Who understands whether we can set crt_static_allows_dylibs: true in https://github.com/rust-lang/rust/blob/cb6fafbdf3b09da28b09fa7e87a24658d77dd02f/src/librustc_target/spec/x86_64_unknown_linux_musl.rs#L10-L22? See its rustdoc. I know of no reason why not.

[mati865]

I've tried that but it requires PIE or PIC literally on everything and it's supper messy.

[sanmai-NL]

Is there documentation about this requirement somewhere? What can others do to gain more understanding of this challenge?

[mati865]

I'm not aware of any docs, once you change it to true you will get dozens of build errors about relocations.

[sanmai-NL]

What about creating a WIP PR replicating your experiment, so that others can see the build log and discuss the problem? Or is there a better way forward?

[smaeul]

@sanmai-NL musl does not support crt_static_allows_dylibs: true. Setting that and then compiling a dylib (or proc-macro) would link a second copy of libc into the crate. Then you'd have two competing copies of global state (e.g. threading implementation and malloc() data structures) in the same program, which would blow up.

crt_static_allows_dylibs: true only works on Windows, because the C runtime there is designed to have multiple copies in the same program. It can do that because it delegates a lot of its heavy lifting to kernel32.dll. See, for example, here.

[sanmai-NL]

AFAIK the procedural macros DSO isn't being linked into a program produced, but loaded by the compiler when compiling the program. Could we make the logic more sophisticated for building procedural macro crates, so that they don't depend on crt_static_allows_dylibs when linking statically? How could we fix this @smaeul? Do you guys also experience this issue at all? It would seem so. If so, using a musl host environment isn't practical yet. For me, this is a blocking issue.

[mati865]

@sanmai-NL you will want to link dynamically all the time when using it as the host toolchain.

In rust-lang/rust#58575 I proposed new triple:

I suggest leaving $ARCH-unknown-linux-musl static for both host and cross target and introducing "alias triple" $ARCH-unknown-linux-dynmusl. It'd be the same as $ARCH-unknown-linux-musl (and use the same libraries to avoid duplication) but it'd link dynamically.

I'll open issue to track musl related things soon.