Dynamic and static linking
Why
Why link dynamically? It ought to
- save disk space,
- save launch-time,
- improve multi-tasking efficiency, or at least its
paging aspect,
- simplify some issues in application management [explain
update scenarios],
- permit sexy architectural possibilities, including
- "package" ...
- hot updating
- several development packages, including all from SunSoft for
Solaris,
give no choice.
Why link statically? I most often do it to simplify deployment.
Deployment of dynamically-linked executable generally requires
coordination across hosts of
- shared-object libraries,
- installation locations,
- installation environment settings,
- settings for compile-, link-, and use-time environment
variables
Dynamic linking often precludes relocations backward across OS versions,
and it's almost always a security headache.
It's generally possible to diagnose at least part of the
linking status of a Unix executable with file(1). For
HP-UX and Solaris,
respectively,
chatr(1) and ldd(1), respectively, are also available. Another
possibility is "odump -sllibloadlist ...", perhaps in the public
domain.
How
Chris Phoenix wrote a nice document on
"Win vs.
Unix linking dynamic load modules".
There are a few
general-purpose
Unix-specific linking concepts that suffice to
solve most problems. Beyond these, I've also identified a few
system-specific observations that have been useful before:
AIX
AIX is different in several regards.
BSD/386
Static (what HP knows as "linking-with-archive ..."): -Wl,-a,archive
Only with static linking is there a hope of backward compatibility
between, for example, 10.01 and 9.07, or 10.2 and 10.01.
Linux
NCR 3600 with MP-RAS 2.03 (SVR4)
Dynamic: use "... -Bexport ..." when linking ...
Casper Dik usefully
surveys
the situation for Solaris 2.5.
SunOS
... -Bstatic ...
Cameron
Laird's personal notes on
dynamic and static linking/claird@phaseit.net