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 .
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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: