3 ms·

1. I'm not certain on the precise binary layouts etc, but I believe the answer is "yes, except Go binaries can't be stripped". In terms of practical usage, they

by aidanhs 10y ago

1. I'm not certain on the precise binary layouts etc, but I believe the answer is "yes, except Go binaries can't be stripped". In terms of practical usage, they'll run on the same machines. 2. This is a long one. The statement you've quoted is false. However, it's both a) a common misunderstanding and b) a sort-of-ok simplification (the full story is much more involved). I'd personally alter it to say "it is technically challenging to statically link glibc". You can read more about the whole musl Rust origin story at [0]. The 'problem' with glibc is that it uses NSS, a feature that allows you to dynamically load libraries installed on the system to let you change how some libc functions work (if neither you nor your libraries use these functions, static linking with glibc works). For example, musl will look up users from /etc/password, whereas with glibc an admin can install an LDAP library, change a config file and all programs using glibc will magically use LDAP. But, you can disable NSS in glibc at compile time [1], which then allows you to truly statically compile with glibc. Go is interesting because doesn't use libc at all (when using the standard compiler)...except when doing some network things that NSS is useful for, when it does link against it. People who want totally static binaries pass a few additional flags to say "don't use NSS, use the Go implementation of these features"...and you then end up with bugs like [2]. 3. Yes [3], but you lose (by default) a) the ability to use shared libraries from the system, b) NSS. Given that one angle Rust is pushed from is "C/C++ replacement", not being able to link to system libraries without using arguably cryptic command line arguments would be a bit sad. But I'm ambivalent about this. [0] https://internals.rust-lang.org/t/static-binary-support-in-rust/2011 https://internals.rust-lang.org/t/static-binary-support-in-r... [1] https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked_programs_need_some_shared_libraries_which_is_not_acceptable_for_me.__What_can_I_do.3F https://sourceware.org/glibc/wiki/FAQ#Even_statically_linked... [2] https://github.com/docker/docker/issues/1715 https://github.com/docker/docker/issues/1715 [3] (specific post from [0]) https://internals.rust-lang.org/t/static-binary-support-in-rust/2011/17 https://internals.rust-lang.org/t/static-binary-support-in-r...

skissane 10y ago
I'm sure I'm not the only person who works in an environment where there are many thousands of Linux and Unix boxes, and they are all configured to use LDAP for /etc/passwd, /etc/group, etc. If a program uses NSS, it will just work; if it tries to read /etc/passwd for itself, it won't find most of the users (including likely the user it is running as). One solution might be if the statically-linked program included an nscd client, since most people using NSS+LDAP will be using nscd for caching.
- JoshTriplett 10y ago
  > One solution might be if the statically-linked program included an nscd client, since most people using NSS+LDAP will be using nscd for caching. No, that's not OK either; many people use other NSS modules, including mdns (for .local names), resolve (for local resolved support), resolving "localhost" (via "myhostname"), and resolving local container hostnames. If you want to resolve any of the things NSS supports, use NSS.
  - skissane 10y ago
    Why can't nscd support those other NSS modules too? (Even if it doesn't work with them at present, could it not be extended to do so?) Rather than having NSS plugins loaded into every process which needs name services, why not centralise all name services in a daemon (whether nscd or sssd or something else)? Then client processes don't need to actually load the NSS code into their own address space, they can just speak a simple protocol over IPC to access this functionality out-of-process.
    - justincormack 10y ago
      Android does something much like that I believe.
cyphar 10y ago
> Go is interesting because doesn't use libc at all (when using the standard compiler)...except when doing some network things that NSS is useful for, when it does link against it. People who want totally static binaries pass a few additional flags to say "don't use NSS, use the Go implementation of these features"...and you then end up with bugs like [2]. Oh god, I completely forgot about that bug. For what it's worth, the technical reasons why Docker had to be linked statically are no longer valid and so it should be able to fix that issue. Unfortunately, "os/user" is lacking some things we need within runC and Docker.
- justincormack 10y ago
  Docker is available statically linked now yes, and it works fine. Although that issue is still open, you have to use dynamically linked version if you want to use these features. Docker is not required as a trampoline any more.
  - cyphar 10y ago
    Heh, I know, I'm a long-time contributor. And I'm the one that actually removed .dockerinit. ;)
- deleted 10y ago
  [deleted]

by aidanhs 10y ago

skissane 10y ago

I'm sure I'm not the only person who works in an environment where there are many thousands of Linux and Unix boxes, and they are all configured to use LDAP for /etc/passwd, /etc/group, etc. If a program uses NSS, it will just work; if it tries to read /etc/passwd for itself, it won't find most of the users (including likely the user it is running as). One solution might be if the statically-linked program included an nscd client, since most people using NSS+LDAP will be using nscd for caching.

JoshTriplett 10y ago
> One solution might be if the statically-linked program included an nscd client, since most people using NSS+LDAP will be using nscd for caching. No, that's not OK either; many people use other NSS modules, including mdns (for .local names), resolve (for local resolved support), resolving "localhost" (via "myhostname"), and resolving local container hostnames. If you want to resolve any of the things NSS supports, use NSS.
- skissane 10y ago
  Why can't nscd support those other NSS modules too? (Even if it doesn't work with them at present, could it not be extended to do so?) Rather than having NSS plugins loaded into every process which needs name services, why not centralise all name services in a daemon (whether nscd or sssd or something else)? Then client processes don't need to actually load the NSS code into their own address space, they can just speak a simple protocol over IPC to access this functionality out-of-process.
  - justincormack 10y ago
    Android does something much like that I believe.

cyphar 10y ago

> Go is interesting because doesn't use libc at all (when using the standard compiler)...except when doing some network things that NSS is useful for, when it does link against it. People who want totally static binaries pass a few additional flags to say "don't use NSS, use the Go implementation of these features"...and you then end up with bugs like [2]. Oh god, I completely forgot about that bug. For what it's worth, the technical reasons why Docker had to be linked statically are no longer valid and so it should be able to fix that issue. Unfortunately, "os/user" is lacking some things we need within runC and Docker.

justincormack 10y ago
Docker is available statically linked now yes, and it works fine. Although that issue is still open, you have to use dynamically linked version if you want to use these features. Docker is not required as a trampoline any more.
- cyphar 10y ago
  Heh, I know, I'm a long-time contributor. And I'm the one that actually removed .dockerinit. ;)
deleted 10y ago
[deleted]