Re: Linking libraries
On Jul 6, 12:05 am, Ian Collins <ian-n...@hotmail.com> wrote:
On 07/ 6/10 12:32 AM, James Kanze wrote:
On Jul 4, 9:40 pm, Ian Collins<ian-n...@hotmail.com> wrote:
On 07/ 4/10 11:59 PM, James Kanze wrote:
[...]
I must admit I'm surprised you favour static linking given your focus on
reducing coupling. Dynamic linking is the build equivalent of
minimising coupling in code.
It's a trade-off. I guess in the end, I like the idea of
knowing the exact program image my user is complaining about.
Mixed versions of dynamic objects is just one more thing which
can go wrong.
I don't know about windows, but a lot of my debug tools
(memory access checking, profiling) can be selectively enabled
on a per-module basis.
Debugging is one possible advantage of dynamic linking. Most
systems do provide some sort of hooking for function calls
accross dynamic object interfaces. But it doesn't seem worth
the extra cost in deployment.
I don't really see an extra cost in deployment. I guess it may be
platform specific, but modern packaging systems solve any dependency
problems (I guess that's the payback for not having to consider link
order dependencies).
The real cost often isn't in deployment, a one off activity, but in
support. If like me you have a number of applications running on
systems, patching a bug in a shared library only requires an update to
that library, not to all the applications that use it.
Yes. And suppose that patch makes the library incompatible with
the other programs which use it. I've seen too many cases of
code which runs with only one specific version of a dynamic
object. And where patching one application breaks three others.
And I like to test what the client is running (in addition to
unit tests). If I'm releasing a new version of X, and it uses
three different dynamically loaded objects, each with three
different versions in the field, that means 81 different
combinations to test. If I link statically, I only have to test
the resulting executable, and I know the program the client runs
is the one I've tested.
Up to a point, of course. I don't statically link libc, and
I can't begin to cover all of the different versions and
combinations of patches which I might encounter.
All of which is to say that there isn't one perfect solution.
If you're a library provider, there are probably a fair number
of cases where providing a dynamically loaded object is
preferrable, *provided* you can freeze your interface, so that
clients can effectively link against any version they might
find. If you're providing an application in the form of an
executable, the cases where you'd want to provide part of the
application as a shared object seem rather rare, however: mostly
cases where you load the library explicitly (the human language
interface, for example).
--
James Kanze