But then dynamic linking definitely normally means
linking every
time the application is started (DLLs for Windows, .so:s for
Linux). Then it's
possible to also do pre-linking where you speed up
future dynamic linking by
processing executables and the installed
libraries and resolving much of the
symbols. I think that's closest of
these to what Google is doing here
(resolving the references is pretty
much what linking is about), and it's hard
to tell if it should be
considered dynamic or static.
The standard
definition for static linking would be doing the linking
at build time
(building an application consists of several
steps, possibly including
compiling and linking). With statically linked
programs in the standard meaning
of that term, the linking is done by
the program vendor before the application,
together with the linked
library, is delivered to the device.
Yet another
aspect on static vs. dynamic linking: With static linking,
the library becomes
part of the program executable file. Typically that
means different
programs
that use the same library contain individual copies of that
library, wasting at
least disk space and usually also RAM. Dynamically
linked programs only "point"
to a library.
This also has the effect that dynamic libraries can often be
updated
independently of the application, as long as they preserve ABI
(Application Binary Interface - the compiled program equivalent of API)
compatibility. This is often quite useful: For example, it's normal that the
code for accessing popular image formats like GIF, JPEG or PNG is
encapsulated
in a dynamic library. All browsers and lots of other
programs then link against
this library. Now, if you find a bug or a
security vulnerability in the
library, you only need to recompile and
update it, not all of the applications
individually. [ Reply to This | Parent | # ]
| 
