Static vs Dynamic Linking

You're forgetting about one common case where libraries are replaced.This is security vulnerabilities. If your application depends on a common library that had a vulnerability, I can fix it without you having to recompile your app.With GLibc or X libraries a vulnerability there would result essentially requiring reinstallation of the entire OS.

Linux distribution fix vulnerabilities in shared libraries all the time.Imagine statically linking openssl having to rebuild tenths of thousands of packages every time there's an update!

I don't think it's so much how you (as an active developer does it) -- granted having to redistribute your app everytime any of (say) 10 bundled dependencies need an update is an inconvenience -- the biggest problem is when you have some old software (without vendor support) that is statically built with some overflow "built in" from an old version of a library.Granted, at some point patches probably won't be backported, but it is convenient to be able to upgra

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 p

Static linking would solve this. You end up with a bigger application and have to do updates every time a library needs a security patch. But you have this anyway if e.g. you release a python application on Windows.

This is certainly very true, and the pessimistic tone of the cat-v article is, to some degree, unwarranted, but it's also worth pointing out the unanticipated problems real life brought.In practice, this is something that happens less often than we'd want:> It's the last that is still crucial and which causes so many problems. When, say, there's a security problem in Webkit, an updated version of the webkit code can be installed, immediately (well, upon restar

There are clearly downsides to dynamic linking but static linking would fail spectacularly when there is a bug in a common library, like libc. One of two things happens:- Some applications are not updated and retain the bug. Extremely dangerous if it is a security bug.- Suddenly your package manager needs to update almost every single application on your system. All the packages in my Ubuntu system is a total of ~1GB. Now that you statically compiled them prepare for a very long download.<

One issue with static linking is that your dependencies will likely have critical CVEs over time. If you keep all your libraries separate on the filesystem, you can just do a "apt update; apt upgrade", and you will have all the latest patches. This will patch security issues in e.g. libssl or libc for all your applications that are dynamically linked against this shared libraries, which can be quite a few. In static binaries, the version of the libraries is not obvious from the outside

There's also the issue that if a library has a vulnerability, you are now reliant on every static binary updating with the fix & releasing a new version.Where-as with the conventional dynamic library world one would just update openssl or whomever & keep going. Or if someone wanted to shim in an alternate but compatible library, one could. I personally never saw the binary compatibility issue as very big, and generally felt like there was a while where folks were getting good at

Wouldn't this raise the issue of application updates ? If the app imports its own libraries, who will take care to update them if a security issue is detected ? That's the point to enforce using shared libraries on unix system.