[MLton] (no subject)
Henry Cejtin
henry@sourcelight.com
Thu, 23 Dec 2004 09:24:24 -0600
Sorry, I was confused about what you said, but I think that you are also
confused about what I am saying.
Note, with dynamic linking the linker at link time (not run time) still
checks to see where symbols come from. If this were not the case, then if
you just compiled
extern void doesNotExist(void);
int
main(void)
{
doesNotExist();
return (0);
}
would not produce any error at compile/link time, only at run time since
doesNotExist might be found at run time in one of the shared libraries.
Given that ld, the linker, knows where symbols will come from at link time,
it would seem like a very good idea to eliminate references to shared
libraries which provide nothing that is used. That is NOT done, and that is
the reason that even if MLton arranged carefully to not call any GMP routines
in compiled code of SML programs that never used IntInf routines, there would
still be a dependency on libgmp.so. (Note, in the 20041109-1 version of
MLton, there is NO dependency on it in executables produced because it
explicitly links with
/usr/lib/libgmp.a
instead of
-lgmp
Of course if the MLton compiled executable actually references any thing in
the libgmp.so then you are going to need it when you run the executable. The
point is that if you have an SML executable which doesn't use IntInf in any
way, say
val _ = print "Hello world0
then it is bad (not horrible, but not good) if the resulting executable
requires libgmp.so to be installed. The set up in 20041109-1 of MLton
achieves that. In fact, but explicitly mentioning /usr/lib/libgmp.a it NEVER
requires libgmp.so to be installed.
Although dynamic linking has several advantages:
executables are smaller.
bugs in shared libraries can be fixed after the executable is linked
code in libraries is shared among all running programs
it is definitely not without its disadvantages:
runtime startup is slower (slightly more than 3 times slower)
you are now dependent on the dynamic libraries being in place at run time
The latter is clearly usually the bigger problem.
The output of nm, in either case, will ONLY list the symbols actually used by
the executable, not all the symbols in the shared library. Although it is
true that in the dynamic case all of the library is mapped in, the linker
knows what is needed and the output of nm shows only that.