[MLton] Compilation crash with FFI on Windows with latest SVN revision (r6960)

[Nicolas Bertolotti]

I have never heard about those "public" and "external" scopes. Have they been introduced recently ?

The same piece of code used to build and run fine with MLton 2007. That's why I am asking (in my point of view, it can be considered as a regression).

I am going to perform some additional tests and let you know.

Thanks

Nicolas

> -----Original Message-----
> From: Wesley W. Terpstra [mailto:wesley at terpstra.ca]
> Sent: Wednesday, October 22, 2008 3:42 PM
> To: Nicolas Bertolotti
> Cc: mlton at mlton.org
> Subject: Re: [MLton] Compilation crash with FFI on Windows with latest SVN
> revision (r6960)
>
> On Wed, Oct 22, 2008 at 2:43 PM, Nicolas Bertolotti
> <Nicolas.Bertolotti at mathworks.fr> wrote:
> > It seems that the latest SVN revision prefixes all symbols with < __imp
> >
> > during code generation.
>
> That's correct.
>
> > This includes FFI functions which do not use the stdcall convention
> which
> > does not appear to be correct (simple C function defined in an external
> C
> > file that is given to MLton together with the SML sources).
>
> You are using the wrong symbol scope. Please change your _import
> "somefn" : ... to _import "somefn" public : ... The problem you see is
> because _import default to external, which means it needs __imp__ to
> be fetched from a DLL. See http://mlton.org/LibrarySupport for some
> (bad) documentation.
>
> > Anyway, this is just a tree in the forest (I'm not sure this expression
> > makes sense in english) because the resulting binary simply freezes.
>
> Can you provide more details? The linking problem you describe should
> be unrelated to the freeze. What was the programming doing when it
> froze?
>
> > Please note that this regression is quite recent as the binary used to
> run
> > almost fine using revision 6698 (I know it is the one that introduced an
> > effective Win64 support but I am really talking about Win32 binaries).
> >
> > ... and when I say "almost", this is because we experience some sporadic
> > failures (the binary freezes) during FFI calls on some machines.
>
> If it froze before, it's quite possible that recent changes just made
> this sporadic behavoiur ... more reliable. ;-)