[MLton] library support

[Wesley W. Terpstra]

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.

Yes.

>   + 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.

Yes.

>   + 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 (??).

All correct.

>  - 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.

Yes.

>  - 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.

Yes.

> 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.