3 ms·
> That seems to be the Go and Rust default approach I think Go tried to go fully static but ran into problems as most mainstream OSes except for Linux do not p
by josefx 5y ago
> That seems to be the Go and Rust default approach
I think Go tried to go fully static but ran into problems as most mainstream OSes except for Linux do not provide a stable system call interface, so applications have to link at least one dynamic library. The Linux system call interface is stable, but expects a C style stack layout and that also bit the Go devs. multiple times. So you can probably go fully static if you are only targeting Linux.
- cesarb 5y ago> I think Go tried to go fully static but ran into problems [...] So you can probably go fully static if you are only targeting Linux. There's yet another problem Go ran into on Linux: resolving hostnames. The official way to resolve hostnames in a glibc-based system is to read /etc/nsswitch.conf, dynamically load the libraries referenced there, and call each of them in the correct order. Go tried to emulate that mechanism, going through glibc only when it saw a NSS module it didn't know, but that caused issues on musl-based systems which used a different mechanism (https://github.com/golang/go/issues/35305 https://github.com/golang/go/issues/35305). And it cannot ever be fully static on glibc-based systems, since there's always the chance of someone adding a new module to /etc/nsswitch.conf (for instance, some Linux distributions have now added the newer "resolve" module to that line, so Go would have to implement yet another one to keep being fully static). The Rust approach of dynamically linking to the shared C libraries (statically linking only the Rust libraries) avoided all these issues.