[MLton] linking with GnuMP

[Henry Cejtin]

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.