Statically link against glibc

[NilsIrl]

Reasons for:

1. Performance. According to this reddit message, 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.
2. Smaller docker containers using FROM scratch. example using musl

It is possible to link glibc statically as demonstrated here.

From what I can tell, on the user facing side, this would be enable using -C target-feature=+crt-static as described in the reference.

[the8472]

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?

[mati865]

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.

[NilsIrl]

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.

(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.

[NilsIrl]

https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynamic

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.

[haraldh]

• because of pthread we need special linking arguments because of the weak symbols.
  -Wl,--whole-archive -lpthread -Wl,--no-whole-archive see also https://stackoverflow.com/questions/35116327/when-g-static-link-pthread-cause-segmentation-fault-why
• for getaddrinfo and gethostbyname glibc uses dlopen() for the nss modules.

[joshtriplett]

@haraldh 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 gcc -static.

[petrochenkov]

Implementation instructions:

• Add an entry for glibc-based targets you want to support to https://github.com/rust-lang/libc/blob/master/src/unix/mod.rs#L295-L357

      #[cfg_attr(feature = "rustc-dep-of-std",
                 link(name = "c", kind = "static-nobundle",
                      cfg(target_feature = "crt-static")))]
      #[cfg_attr(feature = "rustc-dep-of-std",
                 link(name = "c", cfg(not(target_feature = "crt-static"))))]
      extern {}

  (Same as for musl, but "static" -> "static-nobundle", because "static" is undesirable (Distribute libc.a as a separate library instead of bundling it into liblibc.rlib on musl and wasi #72274).)
  Perhaps libm or libpthread will need to be linked in the same way.
• Set crt_static_respected to true in target specifications for glibc-based targets you want to support (in compiler\rustc_target\src\spec).
• Test that it actually works, this will require some building of libstd with cargo overridden libc dependency.

[petrochenkov]

@joshtriplett

I'd be happy to submit the necessary changes, if you can outline what needs doing. (#72274 (comment))

See the comment above.

[joshtriplett]

@petrochenkov Thanks!

[joshtriplett]

I have this successfully working; just waiting on a release of the libc crate containing rust-lang/libc#1899 .