Re: Merits and uses of static vs. dynamic libraries
On Apr 14, 8:12 pm, Tony Strauss <tony.stra...@designingpatterns.com>
wrote:
On Apr 14, 4:35 am, James Kanze <james.ka...@gmail.com> wrote:
On Apr 13, 10:10 pm, Tony Strauss
<tony.stra...@designingpatterns.com> wrote:
On Apr 13, 2:37 pm, peter koch
<peter.koch.lar...@gmail.com> wrote:
[...]
One additional caveat that I've found with shared
libraries and C++ in particular is that it's easy to make
a change that requires recompilation of all clients of the
library but not to be aware of it.
Anytime you change anything in a header file, all client
code must be recompiled. Formally, if all you change are
comments, you're OK, and there are a few other things you
can change, but you can't change a single token in a class
definition. And in practice, the simple rule is: header
file changed=>all client code must be recompiled. (Which is
the way makefiles work, anyway.)
You make it sound so simple :), but at the particular place
where I was working, the rules did not end up being as clear
as you're laying out (naturally).
The rules I just explained have nothing to do with where you
might work. They're part of the language. Something called the
one definition rule, section 3.2 of the standard.
The only simplification I made was the last sentence: any change
in the header requires all client code to be recompiled. In
practice, that's what you get anyway, at least with build
systems (make) that I'm familiar with. The only way you can
avoid it is to play tricks with the time stamps, and that's a
sure road to problems.
The system was large (on the order of 1,000,000 lines of code)
and consisted of many programs (about 150), many instances of
which were running on a machine at any given moment. The
build system was recursive, and Makefiles in a large recursive
build system often will *NOT* recompile all code when a header
file changes.
Then there's something wrong with them. All of the systems I'm
familiar with have some means of automatically maintaining the
dependencies, and you're definitely better off using them.
For instance, if you have this file layout and a recursive
build system (which is very evil but, alas, very common):
There's nothing wrong with recursive build systems---they
correspond to the project organization. But like everything
else, they have to be done right.
Makefile
/library/Makefile
/library/library.h
/library/library.cpp
/program/Makefile
/program/program.cpp
a common pattern is to make a change to the library, build the
library, and then separately build the program.
That's not recursive build. But that shouldn't be a problem.
Obviously, the changes in the library are checked in at the same
time the changes in the headers, and become visible
simultaneously (atomically). Otherwise, of course, nothing
works.
Rebuilding the library does not cause the program to be
rebuilt.
Should it? The important thing is that the program has a
consistent view of the library (including its headers). That
view may not correspond to the latest state, but that shouldn't
matter (unless you're dealing with shared memory, or some such).
Imagine now this build system scaled to the large system that
I described; it's never going to be clear what needs to be
rebuilt when developing and a top level build probably takes
too long to do for each change when testing. While everyone
knew that doing something like changing a header file required
recompiling all dependencies, it was difficult to do in
practice because of the size of the system.
Test deployment also created issues. Imagine that six
programs rely on a library, of which four always are running.
If a developer is making changes to the library for one of the
programs and moves a new version of that program and of the
shared library to a shared test environment (but does not move
new versions of the other programs), then the other programs
will break if they are bounced at some later time (perhaps by
a different developer). Had we been using static libraries,
the existing programs on the machine would not have been
broken by moving in the new program.
You don't use dynamic linking in such cases.
Using C with shared libraries is a little easier, because you
can add functions to a module and preserve compatibility
(though of course you cannot change the size or layout of a
structure safely).
Nor the signature of a function. Nor in many cases the value of
a constant.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34