[MLton] Problem with MinGW

[Stephen Weeks]

> I've been stuck on this for a while now, so thought it time to ask  
> for some backup. :-) Everything about MLton seems to work on MinGW  
> now, except opening files from programs compiled by the fresh  
> compiler. It always fails with EINVAL.
...
> I've put in test code around the Posix_FileSys_open3 method and  
> confirmed that it is indeed getting correct parameters and is failing  
> with EINVAL. I've also tried linking a custom C program against the  
> runtime and calling this method with the same parameters. Then it works.

This sounds a lot like the situation I encountered a while back when
working on the original MinGW port.  See

  http://mlton.org/pipermail/mlton/2004-October/026164.html

where I wrote

  What is blocking is the inability to create a file for saving the
  world.  We need World.save in order to build a binary package.  The
  failure I get is:

    unhandled exception: Fail: MLton.World.save unable to open /tmp/package-mlton-mingw/build/lib/world.mlton due to SysErr: No such file or directory [noent]

  The problem has something to do with createf failing, which we
  discussed before, but never resolved.  See the thread at:
 
    http://www.mlton.org/pipermail/mlton/2004-August/016288.html

Of course we resolved the problem eventually, but I can't find the
solution in the archives or svn log.  I think it had something to do
with confusion about drive mappings, or which gcc was getting called
(Cygwin or MinGW), possibly mixed in with whether things were Cygwin
or MinGW exectuables.  I had exactly the same experience where a
simple C test worked fine.  In fact, IIRC when I called the C compiler
to compile the MLton-generated C/asm by hand things worked fine.  So
the path passed to open meant something different to the
MLton-generated and C-generated executables, perhaps because they had
been compiled in different ways.  Sorry I can't be more precise, but
maybe this will trigger some thought that will help.