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

[Matthew Fluet]

On Tue, 11 Nov 2008, Ville Laurikari wrote:
> By the way, it occured to me if nlffigen should be modified in some
> way.  The trunk version does not include an explicit scope when it
> generates code that uses _address.   Will this be a problem?  I
> suppose importing variables may not work in some circumstances (we
> import only functions at the moment...)

Updating mlnlffigen would be fairly trivial, though I think we need to 
change one of the command line options.  Currently, there is a command 
line option '-linkage {dynamic|static}'.  With '-linkage dynamic', 
mlnlffigen generates code to get the address of a symbol like:

     val h = LibH.libh "sinh"

where LibH.libh : string -> unit -> CMemory.addr; typically, one would 
implement LibH.libh using the DynLinkage module provided by the mlnlffi 
library (which in turn used dl{open,close,...} or the platform 
equivalent).  With '-linkage static', mlnlffigen generates code to get the 
address of a symbol like:

     fun h () = _address "sinh" : CMemory.addr;

The use of the term 'static' is a bit ambiguous --- in the absence of 
symbol scopes, this is the code we would use whether we were pulling sinh 
from libm.a (i.e., link against an archive) or from libm.so (i.e., link 
against shared object).  As I understand it, if the symbol is coming from 
an archive, then 'public' or 'private' is the correct scope (but, I don't 
understand the rules for using one or the other); if the symbol is coming 
from a shared object, then 'external' is the correct scope.

So, the '-linkage' option should probably be refined to 
{dynamic|archive|shared} to distinguish between using the dynamic linking 
loader (with dynamic), using 'public' (with archive), and using 'external' 
(with shared).