SUBMODULE/STDCALL/BIND(C)/Unresolved external

[andrew_4619]

!  subm_link_prob.f90   
module mymod
    use ifwin
    implicit none
    INTERFACE
        MODULE FUNCTION FRED(HDLG) BIND(C,NAME='FRED')
            !DEC$ ATTRIBUTES STDCALL :: FRED
            INTEGER(INT_PTR)                   :: FRED
            INTEGER(HANDLE),INTENT(IN), VALUE  :: HDLG
        END FUNCTION FRED
    END INTERFACE
end module mymod
    
submodule (mymod) mymod_subs
    implicit none
    contains
    module function FRED( hDlg) BIND(C,NAME='FRED')
        implicit none
        integer(INT_PTR)                    :: FRED
        integer(HANDLE), intent(in), VALUE  :: hDlg       
        FRED = 1_INT_PTR
    end function FRED
end submodule mymod_subs

program subm_link_prob
    use ifwin
    use mymod
    implicit none
    integer (INT_PTR) :: iret
    print *, 'Hello World'
    iret = FRED(0_handle)
    print *, iret
end program subm_link_prob

1>------ Build started: Project: subm_link_prob, Configuration: Debug Win32 ------
1>Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]...
1>subm_link_prob.f90
1>Linking...
1>subm_link_prob.obj : error LNK2019: unresolved external symbol _FRED@4 referenced in function _MAIN__
1>Debug\subm_link_prob.exe : fatal error LNK1120: 1 unresolved externals

What is the problem?

[Steven_L_Intel1]

The issue with conflicting binding labels is DPD200411167. I was pointed to 16.2p1 in the standard where it says, "An entity of the program shall not be identified by more than one binding label."

[andrew_4619]

Steve Lionel (Intel) wrote:

The issue with conflicting binding labels is DPD200411167. I was pointed to 16.2p1 in the standard where it says, "An entity of the program shall not be identified by more than one binding label."

Having looked at 2008 I also note:

C1250 (R1225) If MODULE appears in the prefix of a module subprogram and a binding label is specified, it shall be the same as the binding label specified in the corresponding separate interface body.

I ended up in this situation BTW as I had not noticed that the program I wrote to convert create interfaces from modules uppercased  the bind names.....

[Steven_L_Intel1]

Thanks for that too.

[Steven_L_Intel1]

Issue DPD200382120 (wrong decoration for submodule procedure with BIND(C)) will be fixed for 17.0 product release.

[andrew_4619]

Cheers.

There were a number of DPDs relating to submodules and most of the key ones seem to be closed now. One that causes me some continual irritation (mainly because I am set it my ways of working in VS)  is DPD200375967 which is about source folds not working with "module function" and "module subroutine" which means folds are not present with a large proportion of my code now . I suspect it is perhaps just a case of adding some new keywords to a list in the Fortran integration. Would that be likely to make 17.0?

[Steven_L_Intel1]

Andrew, I have asked the developers for an update on that one. 

[Steven_L_Intel1]

Andrew, the developer tells me that they hope to have the submodule/expand issue fixed in either 16.0.4 or 17.0.1.

[andrew_4619]

Good news, thanks. I am loving SM's and the lack of build cascades it is saving loads of time but I am drinking less coffee..... :-)

[Steven_L_Intel1]

Didn't you hear? Coffee is now good for you again (unless you drink it very hot)! Have more coffee!

[andrew_4619]

Yes that was yesterday hot drinks (>65C) might cause cancer. Who drinks coffee at the temp. it hurts! 

[Steven_L_Intel1]

The STDCALL issue (DPD200411145) will be fixed in an update to 17.0 (not in the initial release.)