[MLton-user] mlton-20070826 on mingw

Bernard Berthomieu Bernard.Berthomieu at laas.fr
Wed Dec 12 01:47:29 PST 2007


Hello,

Wesley W. Terpstra wrote:
>> ... we had to remove the declarations of timezone and gettimeofday ...
> There is a patch pending which resolves this. However, by just 
> removing the declaration you will have link errors, because 
> gettimeofday is not consistently defined in a library MLton links (or 
> wants to link) to. The approach I took is to #define gettimeofday to 
> something else in the mingw.h.

It seems to work by simply deleting these from mingw.h.  I agree this is 
not satisfactory,
since gettimeofday is declared in the mingw headers but defined in mlton 
(in mingw.c),
but it is more a mingw problem than a mlton problem.

>> ... I typically install mlton so that libgmp
>> is statically linked with the applications, ... I get the link error:
>>
>>     <mltondir>\lib\mlton\self/libmlton.a(gc.o):gc.c:(.text+0x2ec5): 
>> undefined reference to `_imp____gmpz_cmp'
>>     <mltondir>\lib\mlton\self/libmlton.a(gc.o):gc.c:(.text+0x4289): 
>> undefined reference to `_imp____gmpz_get_str'
>>     <mltondir> etc,
>
> I recently rebuilt a native mingw/w32 MLton, also using statically 
> linked gmp, and I didn't see this problem.
>
> Are you aware that the gmp.h only works for either a static or dynamic 
> GMP, but not both (on windows)? If your prebuilt gmp had a gmp.h for 
> dynamic use, you cannot link programs compiled against it with a 
> static gmp. Try rebuilding gmp from source.

I noticed that gmp.h's are different in the static and dynamic versions 
(I hope the differences
are only relevant in Windows !). This is probably the problem, but 
rebuilding gmp from
sources does not help (I did this).

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.

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 :-(

  Bernard.






More information about the MLton-user mailing list