Export interface redefinition

[netphilou31]

Hi,

I have a problem similar to the one described in the topic https://software.intel.com/fr-fr/forums/intel-visual-fortran-compiler-for-windows/topic/296547 but not exactly the same.

I have a dll which contains numerous exported functions. These functions use the STDCALL calling convention along with the REFERENCE and ALIAS attributes. Some of them are calling other entry points. If I place the interface declaration of the called routine in the calling one everything works correctly. Recently I have created a Fortran module wich contains all the interface déclarations for all the exported routines. My problem is that if I use this module into an exported routine which calls another exported one, it seems that the export vanishes.

Example that works:

subroutine FUNC1(arg)
!dec$ attributes stdcall, reference, alias:'Func1', dllexport :: FUNC1
!dec$ attributes stdcall, reference, alias:'Func2' :: FUNC2

.../...

call FUNC2(arg)

end subroutine FUNC1

subroutine FUNC2(arg)
!dec$ attributes stdcall, reference, alias:'Func2', dllexport :: FUNC2

.../...

end subroutine FUNC2

Example that does not work :

module Interfaces_Decl

interface
subroutine FUNC1(arg)
!dec$ attributes stdcall, reference, alias:'Func1' :: FUNC1
    real(8), intent(in) :: arg
end subroutine FUNC1
end interface

interface
subroutine FUNC2(arg)
!dec$ attributes stdcall, reference, alias:'Func2' :: FUNC2
    real(8), intent(in) :: arg
end subroutine FUNC2
end interface

end module Interfaces_Decl

subroutine FUNC1(arg)
!dec$ attributes stdcall, reference, alias:'Func1', dllexport :: FUNC1
use Interfaces_Decl

.../...

call FUNC2(arg)

end subroutine FUNC1

subroutine FUNC2(arg)
!dec$ attributes stdcall, reference, alias:'Func2', dllexport :: FUNC2

.../...

end subroutine FUNC2

In this case the FUNC1 routine is no more exported and I don't know why.

Furthermore, in case of an unresolved external symbol in FUNC1, the error message is mentionning FUNC1 instead of Func1. This seems to indicate that the interface declaration has changed.

I don't understant what I am doing wrong.

Note 1: if I use

use Interfaces_Decl, only: FUNC2

the problem disappear.

Note 2: if I try to add the DECORATE attribute in both déclarations (module and routine) I get the same error message as in the mentionned topic:

error #7794: Only a function or subroutine subprogram may have the !DEC$ ATTRIBUTES directive DECORATE specifier. [FUNC1]

Best regards,

Phil.

[Steven_L_Intel1]

You're going to have to back out this change. What you have done is called "interface to self" and it is non-standard. We allow this, and will warn you about it if you ask for standards checking, but it is really not a good idea and I strongly discourage you from using it. I can believe that your use of the interface in the module hides the DLLEXPORT in the procedure itself.

[netphilou31]

Hi Steve,

Thanks a lot for your quick answer and your detailed explanation. Fortunately, for the time being only few routines have been modified to use this module. I had considered using this approach to generate automatically new routines that call existing ones (because I want to add a new argument to all of them). So I will have to consider adding the declaration statements inline instead of using the module. So I will go back to the original déclarations.

Best regards,

Phil.

[Steven_L_Intel1]

You can still use the module if you change the USE in each procedure to something like this:

subroutine FUNC1(arg)
!dec$ attributes stdcall, reference, alias:'Func1', dllexport :: FUNC1
use Interfaces_Decl, Exclude=>FUNC1

The idea is to rename away the current procedure name, and now you won't have the export issue.

[netphilou31]

I didn't knew that there was an EXCLUDE option on the use statement, I use the ONLY option frequently. I guess that USing only the required interface will do the job as well but your solution is probably better as it only removes the undesired one.

Phil.

[netphilou31]

Sorry I didn't see that your solution was to redefine the name because the => operator.

Phil.