[MLton] MLton and shared libraries

[Matthew Fluet]

> Since there is no -generate-shared-library in MLton I
> chose the C backend and fiddled a little with gcc and ld
> options. I have succeed in generating a so-file that
> dlopen can open, but I run into core dump later on.
> Right now I am trying to figure out what causes this.
> Being new to shared objects, I am not completely sure
> that the options used are correct.
>> 
> What switches is normally used to generate shared libraries
> with MLton?

Generating shared libraries with MLton is not a supported option at this 
time.  More than likely, the segmentation fault you see is arising from 
the shared library not starting up the MLton runtime properly -- any SML 
function that gets called needs a SML heap available to service allocation 
and garbage collection.  I suspect that somehow you need to indicate to 
gcc/ld that what would have been main() in the executable should be the 
init code of the shared library.

That isn't to discourage, but I think it will take a little hacking of
MLton to properly generate shared libraries.  The two obvious obstacles to
overcome are 1) getting the shared library to initialize the SML heap and
run all the top-level effects (such as allocating and initializing
globals) of the program with exported functions, and 2) ensuring that the 
suffix of the top-level program does not exit, but instead enters a state 
where the program is waiting to service exported function requests.