[MLton] library support

[Matthew Fluet]

On Fri, 12 Jun 2009, Wesley W. Terpstra wrote:
>> 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.

I say this because an un-attributed C function declaration (i.e., one 
without __declspec(dllexport)) would appear to denote a 'private' symbol.

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

I guess the problem is that the C-side defaults are not the same for coff 
as for elf/macho.  That is, if in a .c file I simply write:

int foo(void) { return 1; }

then, as I understand it:

  * on coff, with no attribute, gcc will compile it as 'private';
  * on coff, I need __declspec(dllexport) to get gcc to compile it as
    'public'.

  * on elf/macho, with no attribute, gcc will compile it as 'public';
  * on elf/macho, I need __attribute__((visibility("hidden"))) to get gcc
    to compile it as 'private'.

I infer this from the macros in <src>/runtime/export.h.

It is true that if I were to write:

#include "export.h"
PRIVATE int foo(void) { return 1; }
or
#include "export.h"
PUBLIC int foo(void) { return 1; }

then the macro expansion will insert the appropriate attribute.

But, this doesn't appear to help in the case that you are linking to a 
static library that was compiled naively --- that is, with un-attributed 
function declarations --- on both coff and elf/macho.

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

No, I meant "x86-darwin".  Extending mlton.org/LibrarySupport with the 
list of known good and known bad platforms would be helpful.

> All  "x86" machines from apple support amd64.

But, by default, gcc (and mlton) treat an Intel Mac as an x86 target.