4 ms·

Yeap. I roll my eyes at the people who want to static link everything and think they're somehow better or purer when they're just wasting RAM for nothing.

ericye16 2y ago
Static linker supporter here, not to start a flame war but I like static linking because it means I don't have to worry about version mismatches of shared libraries between what I ship and what the user gets.
- caspper69 2y ago
  Your complaint is more related to how the OS you're running on handles dynamic libraries, rather than anything inherent to dynamic libraries themselves. It is possible to version libraries and serve up the correct version(s) to different applications simultaneously. Now, consider the case of a Linux distro with a few thousand binaries. Should a defect be found in a common library, the burden of updating, say, 10,000 servers might rapidly become a headache. In this case, a shared library probably makes sense. Also, if you want to create extensible software (like a plugin system), dynamic libraries are one of the most expedient and well supported ways to do so. This is not necessarily the traditional use case for shared libs, but it's not uncommon either. And this use case normally doesn't have those versioning problems either (as it leans more to the dynamic side than the shared side). All that being said- static linking also has its advantages; as you stated, you can be guaranteed that your users are executing the library code you intended and that nothing breaks. It's also faster, because you're not waiting for ld.so to resolve your imports at startup & first use (nit: yes, I know you also can force all resolution to finalize at startup at the expense of slightly longer startup time). Further, you can be sure that someone hasn't hooked your library calls to do something nefarious. The downside, of course, is that you have to re-build and re-deploy your entire application on every library's bugfix/security updates. As with anything related to computing, everything has tradeoffs. Some tradeoffs may be dealbreakers for your use case, but they might not be for someone else's.
- pajko 2y ago
  Static linking does not guarantee that you can escape this. There are certain functions which require the same version of libc in the system, which was used for linking. At least this applies to glibc, and sticking with musl or Cosmopolitan might help.
  - immibis 2y ago
    Specifically, the ones that dynamically link. Such as getaddrinfo, or pwent.
kazinator 2y ago
It's not for nothing. Function calls into shared libraries are pretty disgusting.
- worthless-trash 2y ago
  You'll need to elaborate that, because I have read the assembly for a function call in shared libraries and wasn't too disturbed by it... what do you mean ?
- ahartmetz 2y ago
  The first call is through a function pointer to a symbol resolution function, in any subsequent call the function pointer has been patched to directly call the desired function. Seems pretty good to me.
  - kazinator 2y ago
    It's pretty gross. The shared lib call keeps going through a stub in the procedure link table; only the stub has improved after the first call so that it doesn't have to keep fetching the address of the function via the global offset table. The details are architecture specific, but it has overhead pretty much everywhere. On top of that, a register is dedicated to pointing to the global offset table. It has to be saved reassigned and restored as the control flow path takes trips through multiple shared libraries.
adrian_b 2y ago
Static linking does not have to waste any RAM by duplicating code, even if it is frequently implemented in this way. It is possible and not complicated to implement static linking in a way where the executable file retains the metadata about the component object files and also the OS retains some information about the object files that are already loaded in memory as parts of other executables. In this case, when loading an executable, the component objects that are already present in memory can be omitted and the references to them in the executable can be adjusted. While this is not done in the more popular operating systems, due to their preference for the more inefficient dynamic linking, the alternative is still possible. Moreover, it is impossible to say in general which of static linking and dynamic linking wastes more memory. Static linking will have multiple copies of some code, while dynamic linking will have a lot of unused unreachable code, which is superfluous. Moreover, dynamic linking also has some execution time overhead. In practice, with the typical bloated dynamic libraries that are available, I have seen much more memory wasted by dynamic linking than by static linking. When only static linking is used, there is rarely much code duplication besides a small subset of the standard C library, which includes things like the wrappers for system calls and the functions for formatted I/O. Therefore most of the benefit in reducing memory use from dynamic linking would be achieved with a single dynamic library, which should contain only a subset of libc.
up2isomorphism 2y ago
Then your eye will keep rolling when all people asking for a “docker image ” for any existing software.

ericye16 2y ago

Static linker supporter here, not to start a flame war but I like static linking because it means I don't have to worry about version mismatches of shared libraries between what I ship and what the user gets.

caspper69 2y ago
Your complaint is more related to how the OS you're running on handles dynamic libraries, rather than anything inherent to dynamic libraries themselves. It is possible to version libraries and serve up the correct version(s) to different applications simultaneously. Now, consider the case of a Linux distro with a few thousand binaries. Should a defect be found in a common library, the burden of updating, say, 10,000 servers might rapidly become a headache. In this case, a shared library probably makes sense. Also, if you want to create extensible software (like a plugin system), dynamic libraries are one of the most expedient and well supported ways to do so. This is not necessarily the traditional use case for shared libs, but it's not uncommon either. And this use case normally doesn't have those versioning problems either (as it leans more to the dynamic side than the shared side). All that being said- static linking also has its advantages; as you stated, you can be guaranteed that your users are executing the library code you intended and that nothing breaks. It's also faster, because you're not waiting for ld.so to resolve your imports at startup & first use (nit: yes, I know you also can force all resolution to finalize at startup at the expense of slightly longer startup time). Further, you can be sure that someone hasn't hooked your library calls to do something nefarious. The downside, of course, is that you have to re-build and re-deploy your entire application on every library's bugfix/security updates. As with anything related to computing, everything has tradeoffs. Some tradeoffs may be dealbreakers for your use case, but they might not be for someone else's.
pajko 2y ago
Static linking does not guarantee that you can escape this. There are certain functions which require the same version of libc in the system, which was used for linking. At least this applies to glibc, and sticking with musl or Cosmopolitan might help.
- immibis 2y ago
  Specifically, the ones that dynamically link. Such as getaddrinfo, or pwent.

kazinator 2y ago

It's not for nothing. Function calls into shared libraries are pretty disgusting.

worthless-trash 2y ago
You'll need to elaborate that, because I have read the assembly for a function call in shared libraries and wasn't too disturbed by it... what do you mean ?
ahartmetz 2y ago
The first call is through a function pointer to a symbol resolution function, in any subsequent call the function pointer has been patched to directly call the desired function. Seems pretty good to me.
- kazinator 2y ago
  It's pretty gross. The shared lib call keeps going through a stub in the procedure link table; only the stub has improved after the first call so that it doesn't have to keep fetching the address of the function via the global offset table. The details are architecture specific, but it has overhead pretty much everywhere. On top of that, a register is dedicated to pointing to the global offset table. It has to be saved reassigned and restored as the control flow path takes trips through multiple shared libraries.

adrian_b 2y ago

Static linking does not have to waste any RAM by duplicating code, even if it is frequently implemented in this way. It is possible and not complicated to implement static linking in a way where the executable file retains the metadata about the component object files and also the OS retains some information about the object files that are already loaded in memory as parts of other executables. In this case, when loading an executable, the component objects that are already present in memory can be omitted and the references to them in the executable can be adjusted. While this is not done in the more popular operating systems, due to their preference for the more inefficient dynamic linking, the alternative is still possible. Moreover, it is impossible to say in general which of static linking and dynamic linking wastes more memory. Static linking will have multiple copies of some code, while dynamic linking will have a lot of unused unreachable code, which is superfluous. Moreover, dynamic linking also has some execution time overhead. In practice, with the typical bloated dynamic libraries that are available, I have seen much more memory wasted by dynamic linking than by static linking. When only static linking is used, there is rarely much code duplication besides a small subset of the standard C library, which includes things like the wrappers for system calls and the functions for formatted I/O. Therefore most of the benefit in reducing memory use from dynamic linking would be achieved with a single dynamic library, which should contain only a subset of libc.

up2isomorphism 2y ago

Then your eye will keep rolling when all people asking for a “docker image ” for any existing software.