[MLton] NLFFI

[Matthew Fluet]

> > NLFFI basically requires dlopen/dlsym/dlclose
>
> I was wondering if it would be possible to avoid this requirement in
> situations where one knows all the function names at compile time, as
> often seems to be the case.

Possibly.  I note that the ml-nlffi-lib/Doc/mini-tutorial.txt in the
SML/NJ sources says:

[Structure DynLinkage is an interface to dlopen/dlsym.  To get access
to symbols that are already linked into the main program (i.e., SML/NJ's
runtime system), use DynLinkage.main_lib.]

But, note that that is implemented by:

        val main_lib = mkHandle (fn () => checked dlopen (NONE, true, true))


Also, note that dlsym requires you to present the "string" corresponding
to the symbol you are quering.  On the ML side, there isn't anything to
prevent you from constructing this string dynamically, but in practice,
anything coming out of mlnlffi-gen is going to have a constant string.
So, it's just a question of statically linking in the appropriate library.


PS.
This reminds me of yet another annotation I wanted to add to .mlbs.  It
would be great to be able to specify additional linker options.  For
example, the mini-gtk guys have Makefile calls like:

        mlton -output buttons-galore-mlton -verbose 1 \
              -link-opt "`pkg-config --libs gtk+-2.0`" \
              -link-opt mgtk-mlton.o \
              buttons-galore-mlton.cm

It would be great if we could put those link-opt's into mgtk.mlb.