[MLton] MinGW + x86_64
Matthew Fluet
fluet@cs.cornell.edu
Thu, 11 May 2006 07:56:10 -0400 (EDT)
>>> Error: ..\lib\mlton\basic\vector.sml 10.29.
>>> Variable type in structure disagrees with argument signature.
>>> variable: unfoldi
>>> structure: _ -> [ 'a t ]
>>> signature: _ -> [ 'a t * 'b ]
>>>
>>> ... I am guessing this is due to a broken upgrade path? However, I don't
>>> have this problem on the MacOS build. I'm using mlton 20051109 on MacOS
>>> and MLton 20051202 on MinGW.
>>
>> Its a broken upgrade path on MinGW. If you look at mlton/Makefile, there
>> is code to select stubs when compiling with an out of date compiler.
>> However, the stubs don't work with MinGW.
>
> I read the comment and saw that it said 'fork' is unavailable. Ok, fine. So,
> I tried editing the lib/mlton-stubs/mlton.sml to pass spawn* through to the
> real MLton object and re-enabled stubs. However, when the bootstrapped
> compiler runs, it exits immediately with a SysErr (it also is much smaller
> than it should be).
>
> Shouldn't this approach be preferred to manually working around it on MinGW
> for each release? After all, disabling the upgrade path for something as
> minor as a missing fork() call (when we have viable alternatives) is a bit
> overkill.
It is certainly preferred, but I don't think anyone has been successful at
it. I believe that the MinGW binary release is built via
cross-compilation, rather than boostrap on a MinGW machine.
> For now, on MinGW I just hacked my system header. The only type problem there
> was that C_INo_t (ino_t) is actually signed. A quick modification to
> /mingw/include/sys/types.h and MLton compiles further.
>
> At this point, I get past type-checking all the libraries.
> However, now I get a nice type mismatch problem when compiling mllex with the
> bootstrapped compiler.
>
> It happily succeeds at parseAndElaborate, but fails in xmlSimplify/TypeCheck
> after detecting that 'word16' != 'word32' giving a Type error: type mismatch.
> It then helpfully dumps the entire mllex XML IL. =D
>
> Trying a smaller test program:
> val () = print "Hello world\n"
> also gives the same problem.
>
> I would therefore hypothesize that there are two bugs..? One in the basis
> library related to the new type autodetection, where there is a type mismatch
> somewhere. The other, in the front-end which failed to detect this type
> error. I have no idea how to proceed... I'm quite surprised the front-end
> didn't tell me the location in the basis that causes the problem. Also, the
> IL dump doesn't say where in the IL the type error occurred, or I might be
> able to work my way backwards...
That would have been my first hypothesis as well, but it is incorrect.
The IL dump does say where the type error occurred; it is the first few
lines of the dump before "let exception Bind ...". I see from the dump
that the XML type-checker is complaining about:
val IRGRP: word32 =
0x20
val irgrp: word16 =
IRGRP
However, if I look at the core-ML code before the defunctorize pass, I
see:
val IRGRP: word16 = 0x20,
So, for some reason, the defunctorize pass is changing the type of IRGRP
(and other constants) from word16 to word32. That isn't the behavior I
expect.
> I've commited the c-types.sml which works on MinGW (with hacked C_INo_t). I
> think that's all you need to reproduce the compile error on linux, right?
Thanks. I was able to reproduce it, by coping build/lib/self to
build/lib/x86-mingw and adding an entry to build/lib/target-map.
(Technically, this reads the x86-linux constants for the x86-mingw
constants, but it suffices for reproducing the error.)