Do not link statically against libc by default for musl targets #314
Comments
|
This is somewhat related to #290 as well which is basically saying that there's not a great way to control how libc is linked today, unfortunately. |
|
Is it possible to use the existing |
|
Maybe? I'm not sure how invasive of a compiler change that'd end up being... (and it'd definitely be kinda randomly in the back of the compiler) |
|
Solved by https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md and #446, implemented in rust-lang/rust#37545 |
Susurrus
pushed a commit
to Susurrus/libc
that referenced
this issue
Mar 26, 2017
Rename flags to conform to conventions. Resolves rust-lang#290.
danielverkamp
pushed a commit
to danielverkamp/libc
that referenced
this issue
Apr 28, 2020
…#345) * adds {s,u,f}{min,max}{v,p} AArch64 intrinsics * adds {vmov}{n,l} ARM intrinsics Closes rust-lang#314 .
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
By default libc is linked statically for musl targets except for the MIPS architecture: https://github.com/rust-lang/libc/blob/master/src/unix/mod.rs#L197-L200.
This is a problem for custom musl targets like ARM: https://github.com/joerg-krause/rust-cross-libs/blob/master/cfg/armv5te-unknown-linux-musl.json
By design, it's wrong to depend on the architecture if linking is done dynamically or statically. It should depend on the value of
dynamic_linking: https://github.com/rust-lang/rust/blob/master/src/librustc_back/target/mod.rs#L450.The text was updated successfully, but these errors were encountered: