[MLton] library support
Matthew Fluet
fluet at tti-c.org
Thu Jun 11 15:18:44 PDT 2009
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
More information about the MLton
mailing list