Re: Merits and uses of static vs. dynamic libraries
On 13 Apr., 19:44, SG <s.gesem...@gmail.com> wrote:
On 13 Apr., 18:50, Paavo Helde <pa...@nospam.please.ee> wrote:
SG <s.gesem...@gmail.com> kirjutas:
Another selling point would be IMHO:
You can update a shared library (i.e. bug fixes -- assuming binary
compatibility) without the need to recompile every application that
uses it.
I agree with Bo Persson and James Kanze here
Yes, it's more of a catch-22. But I woulnd't consider it to be that
bad (may really depend on the OS and kind of library).
ability to update single
DLL-s in the customer installation creates more problems than solves. T=
o
get such a thing working one needs quite complicated automatic updater,
which would synchronize the customer installation to the last thoroughl=
y
tested combination of DLL-s.
I was more thinking along the lines of *nix, /usr/lib/ and open source
development. If a buffer overflow bug in zlib is found & fixed and the
new version stays binary-compatible I don't want to have to download
and/or recompile Gimp (or any other program that makes use of this
library). :-)
I agree with you - it really depends on the type of application you
write and the type of code in the library. For stuff like zlib and the
OS-near code, a DLL is the way to go.
Other cases where dynamic libraries are warranted is where your
application consists of a group of processes that share common code,
and the cases where your application has an abstract interface that is
more easily supplied (and updated) as a group of DLLs.
Other groups should prefer dynamic libraries.
/Peter