[MLton] building MLton -link-opt -static

[Stephen Weeks]

> A possibly big disadvantage of static linking is that if a bug is
> found in some libc code, you won't see the fix.  This is, I would
> say, non-trivial.

A reasonable point.  But it seems to me just as possible to err the
other way.  That is, in all our testing we use a particular version of
libc.  Then, we ship MLton out into the world and it sees other
versions that we've never tested with.  I could see that being more
likely to cause errors than using the libc that passed all our tests.

> Using libgmp.a instead of libgmp.so is a different thing, which
> makes more sense to me, although even here, you lose the possibility
> of CPU-specific versions ov gmp.

To be clear, I am only talking about building MLton and its tools, not
its behaviour on user programs.  So, I don't see that performance of
gmp matters, since IntInf computation makes up a negligible portion of
compiles.

> I guess my vote (weakly) would be to either only link with libgmp.a,

This would address most of my user-hassle worries.  Do you know any
reasonably portable way to do this?