Hacker News Reader

Comment by RcouF1uZ4gsC | Hacker News Reader

> 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.

View on HN

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.

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.

> 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.

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.

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.

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.

If you can't recompile your application then you are already fucked for security regardless of static or dynamic linking.

And even for vulns in libraries, to me, recompiling and shipping an update is a more trustworthy approach than just hoping that my users are getting library updates from their OS vendors.

Dynamic libraries can be updated independently of the main application, that is the whole point about plugins, and commercial software is a thing.

Yes but they often aren't and you have no control over whether a user will update their dynamic libraries. And you still need to be able to recompile and redistribute your application because you are going to have vulns in your code as well so this hasn't actually saved you the responsibility of recompiling to protect your users.

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

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.

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.

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

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

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

Reply on news.ycombinator.com