[MLton] library support

[Matthew Fluet]

The most invasive change since 20070826 has been the addition of support for
building stand-alone ML libraries.  Honestly, I think this has gotten less
testing and less documentation than it needs, but as long as it doesn't
(seriously) disrupt the building of executables, it won't affect most users.
The one place where it does affect existing users is the proliferation of
scoping attributes for FFI.  If I understand things correctly, the following
summarizes the state of play:

  - Building an executable with only imports (_address/_symbol/_import)
    Either 'private' or 'public' should be used for imports from .o/.a files
    linked statically with the executable; technically, 'private' would be
    the correct choice on coff, while 'public' would be the correct choice on
    elf and macho --- unless the symbol was compiled with the fancy
    __attribute__((visibility("hidden"))) annotation, in which case 'private'
    would be the correct choice.  'external' should be used for imports from
    .dll/.dylib/.so files linked dynamically with the executable.

    + on elf (executables are non-PIC), 'private', 'public', and
      'external' are all treated the same;  thus, no errors if you get things
      wrong.  Indeed, the default ('external') will always work.

    + on macho (x86 executables are non-PIC), 'private' and 'public' are
      treated the same, but 'external' is treated differently.  However, the
      linker will patch things up if you use 'external' where you should have
      used 'private' or 'public'; thus, no errors if you get things wrong.
      Indeed, the default ('external') will always work.

    + on coff (x86), 'private' and 'public' are treated the same, but
      'external' is treated differently; furthermore, linker reports errors if
      you get things wrong.  This differs from previous versions of MLton.
      In previous versions of MLton, we compiled all imports as 'private'; I
      can't find the e-mail now, but I think I recall Wesley asserting that
      the linker would, as a convenience, automatically generate the
      appropriate 'external' stubs if a symbol couldn't be statically
      resolved.  However, this only worked for function symbols, so _address
      of a C global variable exported from a DLL would not have worked (??).

  - Building an executable with exports (_symbol 'alloc'/_export)

    Either 'private' or 'public' should be used for exports to .o files
    linked statically with the executable.  If the client .c file uses the .h
    file generated by -export-header, then you can't get things wrong.


Question: If I infer correctly regarding 'private' vs. 'public' in imports 
above, then I am at a loss as to how one conveniently shares ML code 
between target platforms --- which I thought was the whole reason for 
introducing 'target agnostic' attributes, rather than gcc's target 
specific attributes: __declspec(...) vs 
__attribute__((visibility("..."))).



In any case, something is broken with library support on x86-darwin:

[fluet at fenrir library]$ ./library-all
+ ../../build/bin/mlton -default-ann 'allowFFI true' -link-opt -L. -debug 
true -format libarchive libm1.sml libm1.c
+ ../../build/bin/mlton -default-ann 'allowFFI true' -link-opt -L. -debug 
true -link-opt -lm1 -format library libm2.sml libm2.c
+ ../../build/bin/mlton -default-ann 'allowFFI true' -link-opt -L. -debug 
true -format libarchive libm3.sml libm3.c
+ ../../build/bin/mlton -default-ann 'allowFFI true' -link-opt -L. -debug 
true -link-opt -lm3 -link-opt -lm2 -format library libm4.sml libm4.c
+ ../../build/bin/mlton -default-ann 'allowFFI true' -link-opt -L. -debug 
true -format archive libm5.sml libm5.c
+ ../../build/bin/mlton -default-ann 'allowFFI true' -link-opt -L. -debug 
true -link-opt -lm5 -link-opt -lm4 -format executable -default-ann 
'allowFFI true' -export-header check.h check.sml check.c
/usr/libexec/gcc/i686-apple-darwin8/4.0.1/ld: ./libm5.a(libm5.a.o) has 
external relocation entries in non-writable section (__TEXT,__text) for 
symbols:
_m4_close
collect2: ld returned 1 exit status
call to system failed with exit status 1:
gcc -o check -g /tmp/file6zUOi2.o /tmp/file1JPVB3.o /tmp/filegAcro6.o 
-L/Users/fluet/devel/mlton/mlton.git-svn.trunk/build/lib/self -lmlton-gdb 
-lgdtoa-gdb -lm -lgmp -L/usr/local/lib -L/opt/local/lib -m32 -L. -lm5 -lm4