`DllExport("name")` does not export symbols in Mercury Island/Windows DLLs

I encountered an issue when building a native Windows DLL using Island and Mercury.

The project successfully produces a DLL, but using the documented named form of DllExport does not place the method in the DLL export table.

For example, this does not export int_add:

Public Shared Class Export

    <DllExport("int_add")>
    Public Function IntAdd(a As Int32, b As Int32) As Int32
        Return a + b
    End Function

End Class

The DLL builds successfully, but int_add does not appear in its exported symbols.

I verified the export table with:

llvm-readobj --coff-exports .\Library.dll

However, splitting the export name into a separate SymbolName aspect, and also adding Used, works correctly:

Public Shared Class Export

    <DllExport>
    <SymbolName("int_add")>
    <Used>
    Public Function IntAdd(a As Int32, b As Int32) As Int32
        Return a + b
    End Function

End Class

With this version, llvm-readobj shows the expected exported symbol:

Name: int_add

I also tested the exported function by loading the DLL through LoadLibrary, resolving int_add through GetProcAddress, and calling it from a small C program. The function was found and returned the expected result.

The same issue does not appear to occur in Oxygene. In an equivalent Island/Windows project, the following syntax directly exports the requested symbol:

[DllExport('int_add')]
class method IntAdd(a, b: Int32): Int32;

So the behavior currently appears to be:

Mercury:
<DllExport("int_add")>
    → symbol is not exported

Mercury:
<DllExport>
<SymbolName("int_add")>
<Used>
    → symbol is exported

Oxygene:
[DllExport('int_add')]
    → symbol is exported

Is this a Mercury compiler issue, or is the named DllExport argument not currently supported for Mercury on Island/Windows?

Update: Water version is 13.0.0.3095 (develop)
Built on bajor, 20260626-193532

We can not reproduce this as-is; could you send us a small testcase?

MercuryDllExport33681.zip (2.7 MB)

I have recorded a video showing the complete process, including creating the project, building the DLL, and checking the exported symbols.


whether I made any mistake during the process?

Can you send us the final project from this?

ok here it is. by the way I’ve upgraded water to 1301 and the problem still comes
DllExport.zip (2.7 MB)

Thats good, i’d be worried if to went away on its own :wink:

Good news, this is fixed for vNext. Would you like an interim build, or will coming Friday be sufficient?

1 Like

Let me test it friday

1 Like