[MLton-user] mlton-20070826 on mingw

[Bernard Berthomieu]

Hello,
> What happens I guess is that the decision of whether libgmp can be 
> linked statically or
>> dynamically with applications is frozen when compiling mlton, by the 
>> choice of the particular
>> gmp.h used to built libmlton.a.
> Sounds right.
>
>> When building applications then, one has no other choice than that 
>> made for building libmlton.a,
>> unless the two possible versions of libmlton.a are bundled with mlton 
>> :-(
> You should be able to re-compile the runtime system (yielding a new 
> libmlton.a) without needing to re-compile the compiler itself.  If you 
> have a gmp.h/libgmp.a pair that corresponds to a GMP configured as a 
> static library, then you could download the MLton sources, and then 
> execute 'make dirs runtime' and copy the resulting 
> '<src>/build/lib/self/libmlton.a' (along with libgmp.a) to 
> '/mingw/lib/mlton/self'.  You'll still need a libgmp-3.dll around to 
> run the compiler itself, but the resulting executables should be 
> statically linked to GMP.

Confirmed. I'm not sure the differences between the static and dynamic 
versions
of gmp.h are relevant here, but the way mlton is built definitely is.

Using mingw with gcc4 and the available mlton distribution (and slight 
updates of
runtime/platform/mingw.{h|c}), I could rebuild both variants of mlton 
last week:

- one that links gmp dynamically, equivalent to that available for 
download, and
that does not allow one to link gmp statically with applications;

- one that links gmp statically. I can't figure out why exactly but, 
interestingly, this
version allows one to link gmp either statically or dynamically with 
applications.

Both seem to work. I think it would be a good idea to make the "static" 
version
available for download too as, so far, I can only see advantages in 
using it rather
than the "dynamic" version.

  Bernard.