May 10, 2001, 8:49 AM —
Q: I've heard that an application built using static linking may run faster than a dynamic-linked application using shared libraries. I've also heard static linking is discouraged in Solaris 2. What should I do?
-- Linkless in La Crosse
A: Dynamic linking became the default for Solaris 1 in 1988 with the advent
of SunOS 4.0, and is, of course, the default for Solaris 2. It has several
advantages and, in many cases, offers better performance than static linking.
We'll start by examining the differences between static and dynamic
linking, then move on to the reasons why dynamic linking is
preferred. We'll also look at using dynamic linking to
improve application performance.
I mentioned the difference between interfaces and implementations last month,
but it is relevant so I'll repeat my definitions briefly:
- Interfaces
are distinct from the implementation of "how" it is done. "How"
changes all the time, whereas the intent is to keep "what"
stable. Application stability and portability is available only
by defining and maintaining the relationship between an application
and the system in terms of the interfaces provided.
work. Bugfixes, performance enhancements, and underlying hardware
differences are handled by changes in the implementation. There are
often changes from one release to the next, or even from
one system to another running the same release.
Static linking
Static linking is the original method used to
combine an application program with the parts of various library
routines it uses. The linker is given your compiled code,
containing many unresolved references to library routines. It also gets
archive libraries (for example /usr/lib/libm.a) containing
each library routine as a separate module. The linker keeps working
until there are no more unresolved references and writes out a single
file that combines your code and a jumbled mixture of modules
containing parts of several libraries. The library routines make system
calls directly, so a statically linked application is built to work with
the kernel's system call interface.
Using the default loader options when constructing a program
provides several important properties:
-
Portability
Insulation
linked, you are insulated from bugs or limitations in the
implementation which would otherwise become part of your program.
Evolution
implementation may provide performance or other benefits to your
application that become available simply by running the extant
application against the new libraries.
Quality
of modules and capability for being manipulated independent of any
application yields better testing and ultimately better quality.
Although any bug fixes found in a dynamic version are also applied to
the static implementation, such fixes are not available to application
programs without reconstructing the application. And, the essentially
arbitrary combinations of modules possible with archive libraries are
not tested by SunSoft or any other vendor exhaustively -- the combinatorics
are simply too vast.
Stability
dependencies between software modules that are expressed in terms of
the interfaces through which they interact rather than a (often very
temporal) relationship based on the status and behavior of the
implementation. These relationships can, through emerging tools, be
validated in both their static and dynamic behaviors and thus assure a
level of application portability higher than one currently enjoys and
without the need for constant retesting as the implementation behavior
changes.
