3 ms·

My personal view is that only standard core system libraries should be dynamically linked. Anything that is not totally ubiquitous should be static. That seems

by api 5y ago

My personal view is that only standard core system libraries should be dynamically linked. Anything that is not totally ubiquitous should be static. That seems to be the Go and Rust default approach, or close to it. Link libc and such, but build in more obscure things. The idea of dynamically linking everything doesn’t scale. It asks too much of distribution maintainers and makes them the choke point for every little upgrade.

PaulDavisThe1st 5y ago
So, you link against a GUI toolkit that can be used to display images. Images in many different formats, including some that haven't been used in more than a decade and are unlikely to ever be encountered. Do you want the GUI toolkit linkage to automatically include every object module for every possible image file format in your static image, or do you want the GUI toolkit to use runtime dynamic linkage (explicit or implicit) to import only the modules required for the image formats actually encountered?
- TillE 5y ago
  If I'm distributing binaries as a commercial product, I definitely want the former.
  - PaulDavisThe1st 5y ago
    There are many "commercial products" that run on Linux whose installation includes various *.so files that will be dynamically linked at run time. Are you saying this is a bad idea?
  - TeMPOraL 5y ago
    What about formats that don't exist yet? What about giving you the ability to supply your own encoder/decoder for some niche format you're using?
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.

by api 5y ago

PaulDavisThe1st 5y ago

So, you link against a GUI toolkit that can be used to display images. Images in many different formats, including some that haven't been used in more than a decade and are unlikely to ever be encountered. Do you want the GUI toolkit linkage to automatically include every object module for every possible image file format in your static image, or do you want the GUI toolkit to use runtime dynamic linkage (explicit or implicit) to import only the modules required for the image formats actually encountered?

TillE 5y ago
If I'm distributing binaries as a commercial product, I definitely want the former.
- PaulDavisThe1st 5y ago
  There are many "commercial products" that run on Linux whose installation includes various *.so files that will be dynamically linked at run time. Are you saying this is a bad idea?
- TeMPOraL 5y ago
  What about formats that don't exist yet? What about giving you the ability to supply your own encoder/decoder for some niche format you're using?

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.