Why use dynamic linking for less-popular libraries?

Question

I know the difference between static and dynamic linking. I know why the notion of a library is important. And I even know why you'd want to link something like OpenGL, platform-specific APIs, or OpenSSL dynamically; lots of applications use them (possibly simultaneously), so why load them into memory more than once?

But suppose I'm using a small C++ library I found on GitHub. It's useful and (to the best of my knowledge) bug-free, but far from famous or widely-used, so odds are pretty good that my program will be the only one on a user's machine that uses said library. I could link it either statically or dynamically; in such a case, why would I want to link said obscure library dynamically?

Also, let's say that my project is open source.

Answer 1

1. Because the license demands it for your use case (e. g. lib being LGPL vs. your project being proprietary).
2. Because you want to decouple deployed app and lib version.
3. Because you aren't absolutely sure the lib is bug-free.
4. Because the target distribution(s) provide(s) the lib through their packet manager.
5. Because the lib is used by more than one binary and you want or must minimize the footprint of your app (think embedded systems).

And reasons for static linking:

1. Because the license permits it for your use case.
2. Because you'd like to circumvent the hassle of deploying more than one binary file.
3. Because you are sure there'll be no need to exchange the lib aside from an app update.
4. Because the lib isn't provided [in the required version, at least and reliably] by the packet management of your target system.
5. Because you don't (need to) care for the footprint.

And there are probably other reasons. YMMV, and there's no silver bullet.

Answer 2

^{(I am having a Linux oriented point of view; I don't know Windows, but its DLL could be slightly different than Linux ELF shared object dynamic libraries)}

A shared library is useful as soon as you might have more than one process or one program using it: e.g. two different programs using the same library, or perhaps even two different processes using the same library (indeed, if that library is used by only one program - perhaps running in several processes -, you don't need to make it a library).

Another reason to have some shared library is because you want it to be upgradable independently of the program(s) using it. This is a significant reason, in particular when that library is free software (notably under LGPL license), but the program(s) using it are proprietary.

^{(Grossly speaking, an LGPL-ed library is required to be dynamically linked, notably when used in proprietary applications; and its user should have the freedom to easily upgrade or enhance that LGPL-ed library)}

Very probably, I could afford not using any static library on my Linux system (notice that static libraries matter only for building binaries; they are not relevant to run these statically linked binaries); but I won't be able to avoid using shared libraries (and since they are dynamically linked, I need them to run binaries).