Code change:
Reasons for: . According to , musl caused a program to run 9x slower. Musl is also known to be slower in certain configurations in C. This varies a lot with the use case and some might even see a performance increase with musl. docker containers using . It is possible to link glibc statically as demonstrated . From what I can tell, on the user facing side, this would be enable using as described in .
The reddit thread mentions libm. And another source of speedups might be the malloc implementation (glibc 2.26 introduced thread-local caches). One can already use custom global allocators, maybe it would make sense to link a custom libm too?
First blocker is the license. Glibc is licensed under LGPL, it has dynamic linking exception so one can freely link dynamically to it. Static linking doesn't fall under this exception. I'm not a lawyer but I think Rust would have to be licensed as (L)GPL to fit it. Another thing is glibc doesn't really support static linking, sure it works well for small software but bites you when you need more of it's features.
(Obviously not a lawyer but), I'm pretty sure that as long as the code it is linked against is (L)GPLed, it should work.
Also as long as the program it is linked against is licensed under a GPL compatible license, it is allowed. The MIT license, is compatible. All this information can be confirmed by looking at the above link. You can even link proprietary code against LGPL if you provide the object files.
because of we need special linking arguments because of the symbols. see also for and glibc uses for the nss modules.
The former should be doable. The latter is a tradeoff that people will need to understand if they statically link glibc, and it's something they already have to deal with if they use .
Implementation instructions: Add an entry for glibc-based targets you want to support to (Same as for musl, but -, because is undesirable ().) Perhaps libm or libpthread will need to be linked in the same way. Set to in target specifications for glibc-based targets you want to support (in ). Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.
I'd be happy to submit the necessary changes, if you can outline what needs doing. () See the comment above.
Thanks!
I have this successfully working; just waiting on a release of the libc crate containing .

Related discussion:
text: } pub fn code(&self) -> Option<i32> { <del> // On Linux-like OSes this function is safe, on others it is not. See // libc issue: https://github.com/rust-lang/libc/issues/1888. #[cfg_attr( any(target_os = "linux", target_os = "android", target_os = "emscripten"), allow(unused_unsafe) )] if self.exited() { Some(unsafe { libc::WEXITSTATUS(self.0) }) } else { None } </del> <ins> if self.exited() { Some(libc::WEXITSTATUS(self.0)) } else { None } </ins> } pub fn signal(&self) -> Option<i32> { <del> // On Linux-like OSes this function is safe, on others it is not. See // libc issue: https://github.com/rust-lang/libc/issues/1888. #[cfg_attr( any(target_os = "linux", target_os = "android", target_os = "emscripten"), allow(unused_unsafe) )] if !self.exited() { Some(unsafe { libc::WTERMSIG(self.0) }) } else { None } </del> <ins> if !self.exited() { Some(libc::WTERMSIG(self.0)) } else { None } </ins> } }