[MLton] library support
Wesley W. Terpstra
wesley at terpstra.ca
Thu Jun 11 17:39:29 PDT 2009
On Fri, Jun 12, 2009 at 12:18 AM, Matthew Fluet<fluet at tti-c.org> wrote:
> 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.
It would be nice if some other people would try using it.
"It works for me"!
> + 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.
> - 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
So far so good ...
> technically, 'private' would be the correct choice on coff
I'm not sure why you say this. For an executable, public would be just as good.
If you are building a library, then you will need to match the
public/private exports between all uses with the library, just like on
any other platform.
> 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.
This is all correct.
> 'external' should be used for imports from
> .dll/.dylib/.so files linked dynamically with the executable.
> 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("..."))).
Where's the problem? AFAIK the rules are the same for all platforms:
Match private/public definitions with declarations (in both C and ML).
Use external for things imported from a dynamic library/dll.
> In any case, something is broken with library support on x86-darwin:
I assume you mean amd64-darwin? x86-darwin is not supported for
library generation. All "x86" machines from apple support amd64.
If you meant amd64, then something has broken since I last used it,
because that used to work.
More information about the MLton