[MLton] library support

[Wesley W. Terpstra]

On Fri, Jun 12, 2009 at 4:17 AM, Matthew Fluet<fluet at tti-c.org> wrote:
> On Fri, 12 Jun 2009, Wesley W. Terpstra wrote:
> I say this because an un-attributed C function declaration (i.e., one
> without __declspec(dllexport)) would appear to denote a 'private' symbol.

public/private don't differ when compiling to an executable.
__declspec(dllexport) has no effect then.

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

The above is correct. As for the C-side defaults not being consistent,
there's not much I can do about this.

When compiling to a library, you should be tagging all your methods as
public or private, so the default doesn't matter. When compiling to an
executable private/public are the same, so the default doesn't matter.

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

Yes. For libraries this means you need to tag every function, but
properly managed libraries have always required that.

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

If you are statically linking, then you're talking about one of two cases:
1) you are creating an executable:
private/public doesn't matter. just pick one.
2) you are creating a dynamic library:
this has always been an area requiring special attention since the
static library needs to have been compiled (and tagged) appropriately.

> No, I meant "x86-darwin".

I can't recall, but I think the c-codegen works on x86-darwin. That
script tries all codegens, however. Try just using the c-codegen?

> Extending mlton.org/LibrarySupport with the list
> of known good and known bad platforms would be helpful.

The native x86 codegen on darwin is the only case I know of that is
broken. I haven't tried it on the more exotic ports like solaris, but
it should (at least in principle) work since those use the c-codegen.