4 ms·

> the vast majority of the shared ecosystem depends on shared libraries/dynamically linked libraries for the standard. The more I use C and C++, the more I am

> the vast majority of the shared ecosystem depends on shared libraries/dynamically linked libraries for the standard. The more I use C and C++, the more I am convinced that shared libraries are the biggest technical debt for the whole ecosystem. It is these shared libraries that are the driving impetus behind “ABI stability”. It is because of shared libraries that we can’t have nice performance or safety enhancing features. Right now the C and C++ ecosystem is groaning under the weight of shared library technical debt.

krastanov 4y ago
Wasn't dynamical linking crucial 20 years ago, when drive space and bandwidth were expensive?
- dralley 4y ago
  It's still pretty important today for things like security-critical libraries, libc, plugin systems, etc. However it is probably overused relative to the situations where it is genuinely useful.
  - smitty1e 4y ago
    Hence the increasing popularity of docker for interpreted projects. However, if we're decoupled from the system .so files, then the 'Hell' of the The Famous Article might be reduced to a Purgatory.
Gibbon1 4y ago
My dog in this hunt is I don't care about ABI stability because everything is statically linked in my world. And when I see this stuff my sour thought is why aren't they versioning their ABI's? I remember a friend in the dark ages worked on a mixed Pascal and C codebase and they had some tool that generated an adapter layer between the two. All it usually did was flip stuff around on the stack before calling the routine. And then clean things up before returning.
intelVISA 4y ago
I haven't used a shared lib in many years thankfully, outside of OpenSSL most libs aren't too painful to link statically.
- mburee 4y ago
  And glibc, but most people interested in static linking are using musl/dietlibc/uclib anyways
pjmlp 4y ago
Those shared libraries are a way to create plugins for commercial software. Surely one can use OS IPC instead, like we used to do during the days static linking ruled the compiler world, but then don't complain about higher resource usage when every single plugin is its own process.
- RcouF1uZ4gsC 4y ago
  > Those shared libraries are a way to create plugins for commercial software. That is an entirely reasonable use. And one that can have specific types and ABI guarantees for the commercial software and the plug-in. In addition, this would only be required if you were the developer of the commercial software or a plug-in. One example of this is COM which had specific types and memory allocation/deallocation. However, the case where the C standard library is being dynamically linked, forces everyone to pay the price for ABI stability.
  - pjmlp 4y ago
    Except that the C standard library is compiler specific, only in the UNIX world it blends with the OS API, due to their symbiotic relationship.
- UncleMeat 4y ago
  It used to be the case that resource limitations meant that shared libraries were meaningfully more efficient. I know that some software communities like to complain about modern software bloat but statically linking everything is so incredibly valuable across so many different dimensions that it is absolutely worth the cost. Heck, modern link-time optimization probably means that applications run faster despite the code-size bloat. Shared libraries not only require this absolutely crippling adherence to the ABI they also are a security mess since you need updates from both your software provider and your operating system vendor to ensure that anything is safe.
  - pjmlp 4y ago
    Static linking is even worse in what concerns security unless you can compile the world from scratch, every single time a new update comes out.
gpderetta 4y ago
How would you link against, say, an hardware specific libopengl.so without shared libraries?

krastanov 4y ago

Wasn't dynamical linking crucial 20 years ago, when drive space and bandwidth were expensive?

dralley 4y ago
It's still pretty important today for things like security-critical libraries, libc, plugin systems, etc. However it is probably overused relative to the situations where it is genuinely useful.
- smitty1e 4y ago
  Hence the increasing popularity of docker for interpreted projects. However, if we're decoupled from the system .so files, then the 'Hell' of the The Famous Article might be reduced to a Purgatory.

Gibbon1 4y ago

My dog in this hunt is I don't care about ABI stability because everything is statically linked in my world. And when I see this stuff my sour thought is why aren't they versioning their ABI's? I remember a friend in the dark ages worked on a mixed Pascal and C codebase and they had some tool that generated an adapter layer between the two. All it usually did was flip stuff around on the stack before calling the routine. And then clean things up before returning.

intelVISA 4y ago

I haven't used a shared lib in many years thankfully, outside of OpenSSL most libs aren't too painful to link statically.

mburee 4y ago
And glibc, but most people interested in static linking are using musl/dietlibc/uclib anyways

pjmlp 4y ago

Those shared libraries are a way to create plugins for commercial software. Surely one can use OS IPC instead, like we used to do during the days static linking ruled the compiler world, but then don't complain about higher resource usage when every single plugin is its own process.

RcouF1uZ4gsC 4y ago
> Those shared libraries are a way to create plugins for commercial software. That is an entirely reasonable use. And one that can have specific types and ABI guarantees for the commercial software and the plug-in. In addition, this would only be required if you were the developer of the commercial software or a plug-in. One example of this is COM which had specific types and memory allocation/deallocation. However, the case where the C standard library is being dynamically linked, forces everyone to pay the price for ABI stability.
- pjmlp 4y ago
  Except that the C standard library is compiler specific, only in the UNIX world it blends with the OS API, due to their symbiotic relationship.
UncleMeat 4y ago
It used to be the case that resource limitations meant that shared libraries were meaningfully more efficient. I know that some software communities like to complain about modern software bloat but statically linking everything is so incredibly valuable across so many different dimensions that it is absolutely worth the cost. Heck, modern link-time optimization probably means that applications run faster despite the code-size bloat. Shared libraries not only require this absolutely crippling adherence to the ABI they also are a security mess since you need updates from both your software provider and your operating system vendor to ensure that anything is safe.
- pjmlp 4y ago
  Static linking is even worse in what concerns security unless you can compile the world from scratch, every single time a new update comes out.

gpderetta 4y ago

How would you link against, say, an hardware specific libopengl.so without shared libraries?