On Jul 12, 2008, at 2:40 PM, Matthew Fluet wrote:
> And be prepared to wait a while for the SML/NJ compiled MLton to
> compile MLton. Of course, if you are interested in compiling a
> program other than MLton, after 'make nj-mlton', you'll have a
> '<src>/build/bin/mlton' that can be used to compile programs. This
> SML/NJ compiled MLton will be slower than a MLton compiled MLton,
> but possibly a faster route to your final goal than bootstrapping.
Thanks for the tip! This worked well, and I was able to use the output
of nj-mlton to attempt some compilation, though I was never able to
get a full compilation of mlton to work. SML/NJ ran out of heap on my
machine with its paltry 2 GB of RAM :-)
> I don't think there have been any fixes to the Windows FFI since
> 20070826 that would affect the treatment of stdcall functions.
>
> But, it looks like the 16-byte alignment is bumping the size of the
> actual argument area, but also being used in the stdcall name
> mangling. You probably need to patch like the following:
Indeed, this fix resolved most of my linker issues! With just a little
bit more hacking, I got it compiling programs - there were a few small
issues around objects being emitting that called usleep (which appears
to have been deprecated and removed from the cygwin libc), though that
was easily kludged with a thunk.
Sadly, the generated binary is not valid. While I frankly am
suspicious of either the cygwin tool stack or my own mistakes, I'll
pass along anything I discover related to MLton.
Thanks again for the help!
- Lars
_______________________________________________
MLton mailing list
MLton@mlton.org
http://mlton.org/mailman/listinfo/mlton
(text/plain)