An excellent read. Moreover, most linkers these days have the ability to strip out unused code from your executable if you are using static linkage.
That means if your tiny executable uses just some methods of a gigantic library, it can do so an it will still stay tiny. Contrast that with dynamic linkage where in practice the whole gigantic library has to ship with your executable because you can never be sure that the host will already have the right version of libGigantic installed. What a mess.
Shared libraries are the reason a lot of app installations are several GB these days. And I dare say that 99.x % of the code that's shipped with an installation package never gets used by the app installed and that most compiled app code would comfortably fit on a couple of floppy disks if static linkage was used rigorously.
That means if your tiny executable uses just some methods of a gigantic library, it can do so an it will still stay tiny. Contrast that with dynamic linkage where in practice the whole gigantic library has to ship with your executable because you can never be sure that the host will already have the right version of libGigantic installed. What a mess.
Shared libraries are the reason a lot of app installations are several GB these days. And I dare say that 99.x % of the code that's shipped with an installation package never gets used by the app installed and that most compiled app code would comfortably fit on a couple of floppy disks if static linkage was used rigorously.