[MLton] linking with GnuMP

[Wesley W. Terpstra]

On Thu, Dec 23, 2004 at 06:50:58AM -0600, Henry Cejtin wrote:
> No, it isn't just the call to gmpn_set_str that causes the libgmp to be
> needed.  If you just write hello world in C (absolutely no GMP calls at all)
> and then you compile it with -lgmp and run ldd on the resulting executable,
> you will see that it needs libgmp.so.*.  That is the problem.

You don't seem to have understood what I said.

By linking statically with libfoo.a (with -lfoo or /usr/lib/libfoo.a is
irrelevant), you get all those symbols needed to satisfy the dependencies
from your object files transitively. That means mpn_set_str pulls in a whole
lot of symbols because it needs them and you used it.

By linking dynamically with libfoo.so you import _no_ symbols at link time.
Instead, your program lists those unresolved symbols in you application it
found in some library at link time. Then, at runtime, the entire .so is
mmap'd into your program and unsatisfied references in your program are
resolved with the mmaped .so.

I hope this explains why the static linked MLton lists more symbols than the
dynamic one. The dynamic one only listed the symbols unresolved by it at
link time whereas the static one recursively pulls in what it needs from the
library and pastes them in.

Incidentally, dynamic linking is nearly always the preferred behaviour on a
linux machine. In fact, if MLton is statically linked to libgmp on debian,
that is a bug. The only situation static linking on debian is preferred is
when the API of a library breaks compatability every release and/or the
library maintainer has been shown incompetent to maintain the library's
soname. Neither is true for libgmp. Sometimes it is a small bit faster
to statically link than dynamically, but this is rarely a deciding factor.

The reasons for dynamic linking include:
1. bugs fixed in the library need not require a rebuild of every dependent
   application (this was a real problem for debian with libz security bugs)
2. it is possible to use a different, compatible library to satisfy the link
3. the memory footprint of the combined system is reduced from sharing

(Btw, because of what I just explained you can get observably different
behaviour depending on if a library is statically linked or dynamically. The
most obvious example is a global variable with a constructor. In the static
case, this object will not be included if not referenced, and therefore the
constructor won't run. In the dynamic case, the whole library is loaded
regardless of what you actually use, and the constructor is run.)

-- 
Wesley W. Terpstra