[MLton-user] A few questions

[David Hansel]

Wesley W. Terpstra wrote:
> On Dec 12, 2007, at 10:00 AM, David Hansel wrote:
>> I downloaded the environment that Wesley had put together.  It _almost_
>> works, but for any non-trivial part of our sources I get a link error
>> about the missing symbol "__imp___difftime64".  I guess it's the same
>> problem as what Wesley mentioned in his post about the "date" regression
>> failing.  Any suggestions on how to work around that?
> 
> You can modify the file runtime/basis/System/Date.c where there is
>> /* The idea for Date_localOffset comes from KitV3 src/Runtime/Time.c */
>> C_Double_t Date_localOffset(void) {
>>   time_t t1, t2;
>>
>>   t1 = time(NULL);
>>   t2 = mktime(gmtime(&t1));
>>   return difftime(t2, t1);
>> }
> If you make the last line
>     return 1.0*(t2-t1);
> ... you might get it to work. However, until I am back home, I only have
> a powerpc, and can't check this for you.
> 
> If you want to try this, get a copy of the svn mlton, apply my patch,
> change into the runtime directory and "make TARGET=x86_64-pc-mingw32" to
> build the runtime. Copy the resulting libmlton.a into
> /mingw/lib/mlton/x86_64-pc-mingw/.

Thanks,  that got me somewhat further.  Next problem I am facing is
(apparently) about the "Time.now()" function.  Trying to compile the
following code:

fun foo() = Time.now()
val _ = print("Hello World!\n")

results in "undefined reference to _Time_sec and _Time_usec" errors.
If I just add stubs for Time_sec() and Time_usec() functions (just
returning 0) in runtime/basis/System/Time.c and recompile the runtime
then the compile goes through but when starting the executable,  nothing
is printed.  The program just terminates,  no segfault, no unhandled
exception but also no "Hello World".
If I comment out the "fun foo()" line and recompile then the program
runs fine.  Note that function foo is never actually called.
Any ideas what could be going on and how to fix it properly?

> Just to be clear: there seem to be a number of bugs in the mingw/win64
> port. Don't trust this toolchain for anything important! 

No worries,  our goal currently is just to (hopefully) have a alpha/beta
version of our product on Windows x64 by the end of 2008.  Our customers
usually move very slowly to new OS's (some are just now contemplating to
move from Windows 2000 to XP).  So there's (probably) plenty of time
until a native 64 bit port is actually needed.  We are currently just
trying to see if it's feasible and how much work is still needed.  Of
course the fact that it's not urgent also means that I cannot spend too
much time on this but I would like to keep the ball rolling by helping
as much as possible.

David