Since the previous attempt to build C libraries with MLton seems to have fizzled out, I have taken it over. :-) The attached patch adds support for shared and static libraries to MLton. So far, the shared libraries probably only work on *nix. I have yet to make DLLs or dylibs for windows and mac osx respectively. However, the patch has already grown large enough and seems stable enough that I think this is a good check-point for committing it. I have tested all the codegens with all three compile modes (executable, archive, library) and they all work except amd64+shared. The problem here is that the output amd64 assembly code is not PIC. The amd64 codegen needs to be changed to use relocatable symbols, which shouldn't be too hard. In any case, both C and bytecode work on amd64. The x86 codegen also is not PIC, but x86 shared libraries work even when not relocatable. Nevertheless, when the amd64 codegen is updated, the x86 should be as well. Here is a summary of the changes: * Add a new header export.h to control symbol visibility * Correctly tag all symbols in the codegen (and related headers) * Compile the runtime and gdtoa with hidden (internal) visibility only * Add an option to control output format (executable,library,archive) * Add an option to configure the path to 'ar' * Expose the current format in MLton.Platform.Format * Add two functions LIBNAME_open and LIBNAME_close to every codegen * Fix a bug where returnToC could leave inconsistent stack/heap, causing a segfault on the first GC after the main thread returns. (This only affected the C and bytecode codegens) * Add a PIC version of mlton and gdtoa for relocatable libraries * Add appropriate link flags based on output format * Don't output a main function in library code * Set the suffix of library to returnToC (involves saving the current thread, creating a thread to perform the return, then restoring the saved thread from the runtime) What remains to be done: * Make the amd64/x86 codegens output PIC code when format = Library * Test whether 'gcc -shared' suffices for a .dll, If it does, modify the '.so' prefix for the MinGW/cygwin targets. * Test whether 'gcc -shared' suffices for a .dylib. If it does, modify the '.so' prefix for osx targets. I would commit this myself as I'm fairly confident I didn't break anything, but I've misplaced my password. -.- When committing, please try to resist changing the patch too much, because I spent a lot of time testing it and would rather not have to do it all again.