Why aren't my fortran functions exported when using the BIND(C, NAME="name") attribute

Question

I am used to using the following syntax

    subroutine CalcA(A,N)
    !DEC$ ATTRIBUTES DLLEXPORT :: CALCA
    !DEC$ ATTRIBUTES ALIAS:'CalcA' :: CalcA
    IMPLICIT NONE        
    ...
    end subroutine CalcA

which produces an exported function in a .dll

So now I am trying the new ISO_C_BINDING with the following code

    subroutine CalcA(A,N) BIND(C, NAME="CalcA")
    USE, INTRINSIC :: ISO_C_BINDING
    IMPLICIT NONE        
    ...        
    end subroutine CalcA

But the export function is not created

So what am I missing here? How is the new iso_c_binding going to replace the deprecated !DEC$ ATTRIBUTE DLLEXPORT declarations?

PS. I am on Intel Fortran XE 2013 on a Win7-64 platform through VS2010.

Answer 1

As Hans suggests, the procedure wasn't exported because the linker wasn't asked to export it.

The binding label in the BIND clause (the ISO_C_BINDING module is not relevant to the discussion) practically sets the "linker name" of the procedure (similar to what ATTRIBUTES ALIAS does) and does so in a manner that is consistent with C. The BIND clause also sets the calling convention to be C compatible (similar to ATTRIBUTES C). The collective effect of the BIND clause also includes that of ATTRIBUTES DECORATE (and there may be other subtle differences between the collective compiler directive attributes and the clause that I've no considered).

There are at least three ways of marking a procedure such that it is exported in a DLL:

• entries in the object file that holds the procedure (this is how ATTRIBUTES DLLEXPORT works with ifort).
• entries in the EXPORTS section of a module definition file (.DEF) that is passed to the linker at link time.
• command link arguments to the linker itself (/EXPORT:xxx).

What's best for you depends... some prefer to have in-source documentation of the export, others find the visual appearance and non-standard nature of compiler directives intolerably odious.