[MLton-user] SVN r6941 MLton/MinGW32 and FFI

[Wesley W. Terpstra]

On Tue, Nov 11, 2008 at 2:36 PM, Matthew Fluet <fluet at tti-c.org> wrote:
> It is one of the examples from <src>/doc/examples/ffi.
> These examples really should work 'out of the box'.

I didn't know about these files. I've started updating them to use
symbol scopes. I've noticed a couple of things:

1. ffi-import.c uses GC_getArrayLength from "platform.h"! Is this
really supposed to be user-accessible? If yes, should it be a private
symbol only accessible within the DSO, a public symbol (in which case
it needs a libname_ prefix), or both?
2. iimport.c uses dlopen/dlclose/dlsym. platform/mingw.c defines
these... which is a problem since the runtime is statically linked,
but libdl is dynamically linked. Perhaps these should be public
libname_ symbols, private MLton_dlopen/close/sym, or both?

What would make most sense to me:
* MLton_{dlopen,dlclose,dlsym,getArrayLength} are private symbols
available within the DSO
* GC_getArrayLength is also a private alias for compatibility
* libname_getArrayLength are public symbols available to users of a
DSO. Perhaps the dl* symbols too.

>> See http://mlton.org/LibrarySupport , suggestions to improve the
>> documentation are welcome.
>
> If the symbol scopes can't be given sensible defaults for executables that
> match the behavior of previous versions, then they really need to be
> documented as well at:
>  http://mlton.org/ForeignFunctionInterfaceSyntax

I agree. However, that page corresponds to the release version of
MLton, which doesn't have symbol scopes.

I'm also beginning to wonder if perhaps imports should default to
public instead of external given the number of people who've run into
the __imp__ link error. The plus side is that public would make
anything that worked before continue to work (MinGW stubs would see to
that). The downside is that any cases that silently failed before will
continue to do so. AFAIK, the only silently failing case is: you get a
different _address that doesn't compare to equality with what other
parts of the program see for functions. _import'ing a variable as
public from a DLL will just flat-out fail at link time, so it's not
silent.