2 ms·

The end user gets a single statically linked binary which is what matters. The quoted sentence refers to distro maintainers providing new binaries.

by greyw 4y ago

Joker_vD 4y ago
Ah, so I (the programmer) build object files, send them to the distro maintainers, they link them with their specific versions of the libraries, ands send the resulting executable binary to me/other users. ...that's remote dynamic linking, only with (potentially) human intervention in the loop. I kinda see how it would have worked better if the distro maintainers cared about package quality and speedy updates but they don't (bacause they physically can't, it's way too much effort for way to few people). Look, I don't argue that dynamic linking has zero problems — heavens know how much I've struggled with glibc but that's mostly because glibc is bloody insane. The whole slew of GNU dynamic-linking-related extensions to ELF is insane, now that I think of it.
- greyw 4y ago
  The distro maintainers take your source code and package it. If they need to update the program due to an outdated dependency they don't need to recompile the whole program but rather just relink their cached object files with the newer version of the static library (if applicable).
  - Vogtinator 4y ago
    Object files are compiled code with the API and ABI already baked in. This approach effectively combines the downsides of static and dynamic linking.
    - greyw 4y ago
      In GNU/Linux, static libraries are precompile object files (.a are nearly indistinguishable from .o files) Obviously it is not the same at all (LTO, inlining etc. Indeed in some cases API and ABI breakage requires you to recompile your program from scratch. This is not differnt from dynamic libraries where ABI breakage is only discovered during runtime. The use case Im talking about tough is your classical 3 bugfix in a library.

The end user gets a single statically linked binary which is what matters. The quoted sentence refers to distro maintainers providing new binaries.

by greyw 4y ago

The end user gets a single statically linked binary which is what matters. The quoted sentence refers to distro maintainers providing new binaries.

Joker_vD 4y ago

Ah, so I (the programmer) build object files, send them to the distro maintainers, they link them with their specific versions of the libraries, ands send the resulting executable binary to me/other users. ...that's remote dynamic linking, only with (potentially) human intervention in the loop. I kinda see how it would have worked better if the distro maintainers cared about package quality and speedy updates but they don't (bacause they physically can't, it's way too much effort for way to few people). Look, I don't argue that dynamic linking has zero problems — heavens know how much I've struggled with glibc but that's mostly because glibc is bloody insane. The whole slew of GNU dynamic-linking-related extensions to ELF is insane, now that I think of it.

greyw 4y ago
The distro maintainers take your source code and package it. If they need to update the program due to an outdated dependency they don't need to recompile the whole program but rather just relink their cached object files with the newer version of the static library (if applicable).
- Vogtinator 4y ago
  Object files are compiled code with the API and ABI already baked in. This approach effectively combines the downsides of static and dynamic linking.
  - greyw 4y ago
    In GNU/Linux, static libraries are precompile object files (.a are nearly indistinguishable from .o files) Obviously it is not the same at all (LTO, inlining etc. Indeed in some cases API and ABI breakage requires you to recompile your program from scratch. This is not differnt from dynamic libraries where ABI breakage is only discovered during runtime. The use case Im talking about tough is your classical 3 bugfix in a library.