Repository navigation
Cannot build statically linked cargo on musl with RUSTFLAGS="-C target-feature=+crt-static" #5266
Description
$ 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.
Reacted by Kornel, Vlad Frolov, Sander Maijers, Rust and Ameya Shenoy
Reacted by Rust
Reacted by Rust and Alexander F. Rødseth
Activity
[-]Cannot build statically linked cargo on musl[/-][+]Cannot build statically linked cargo on musl with RUSTFLAGS="-C target-feature=+crt-static"[/+]sanmai-NL commentedon Mar 17, 2019
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 commentedon Mar 18, 2019
It's disabled in Rust: https://github.com/rust-lang/rust/blob/cb6fafbdf3b09da28b09fa7e87a24658d77dd02f/src/librustc_codegen_utils/link.rs#L156
sanmai-NL commentedon Mar 18, 2019
Who understands whether we can set
crt_static_allows_dylibs: truein 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 commentedon Mar 18, 2019
I've tried that but it requires PIE or PIC literally on everything and it's supper messy.
sanmai-NL commentedon Mar 18, 2019
Is there documentation about this requirement somewhere? What can others do to gain more understanding of this challenge?
mati865 commentedon Mar 18, 2019
I'm not aware of any docs, once you change it to true you will get dozens of build errors about relocations.
sanmai-NL commentedon Mar 18, 2019
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 commentedon Mar 19, 2019
@sanmai-NL musl does not support
crt_static_allows_dylibs: true. Setting that and then compiling adylib(orproc-macro) would link a second copy oflibcinto the crate. Then you'd have two competing copies of global state (e.g. threading implementation andmalloc()data structures) in the same program, which would blow up.crt_static_allows_dylibs: trueonly 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 commentedon Mar 19, 2019
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_dylibswhen 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 commentedon Mar 19, 2019
@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'll open issue to track musl related things soon.
ehuss commentedon Mar 18, 2020
@mati865 Can this issue be closed now?
mati865 commentedon Mar 18, 2020
@ehuss I'm no longer actively using musl target but I suppose it's fixed.
ehuss commentedon Mar 18, 2020
OK, I'm going to close. I believe the default on nightly musl is +crt-static, but not for proc-macros (via rust-lang/rust#69519). I think specifying it as an explicit arg still overrides the proc-macro, so probably don't need to explicitly specify
+crt-static. If I'm misunderstanding the issue, feel free to re-open.