Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28629 Discussions

Linking problem between Fortran DLLs

Ted_Lillys
Novice
541 Views
I have a need to call a subroutine in one DLL from another DLL. I can compile the called DLL fine. When I try to compile the calling DLL, I get the LNK2019 error:

1>INPUT.obj : error LNK2019: unresolved external symbol __imp__ROADWAYEXFILTRATION@16 referenced in function _QUERY

The following code snippets show the declaration of the exported routine and the interface in the calling routine

Exported subroutine[fortran]Subroutine ROADWAYEXFILTRATION(VVFLAG,IFIDL,EffExfilRate,IFLAG) ! Expose subroutine RoadwayExfiltration to users of this DLL !DEC$ ATTRIBUTES DLLEXPORT :: ROADWAYEXFILTRATION !DEC$ ATTRIBUTES ALIAS:'ROADWAYEXFILTRATION':: ROADWAYEXFILTRATION implicit none LOGICAL (2), INTENT(IN) :: VVFLAG INTEGER (2), INTENT(INOUT) :: IFIDL REAL (8), INTENT(OUT) :: EffExfilRate INTEGER (2), INTENT(INOUT) :: IFLAG [/fortran] Imported subroutine via interface declaration
[fortran]subroutine QUERY (DBname,WMUType,IFLAG) IMPLICIT NONE INTERFACE SUBROUTINE ROADWAYEXFILTRATION(VFLAG,FID,EffExfilRate,IFLAG) !DEC$ ATTRIBUTES DLLIMPORT :: ROADWAYEXFILTRATION LOGICAL (2), INTENT(IN) :: VFLAG !verbose flag - generates output to a log file INTEGER (2), INTENT(INOUT) :: FID REAL (8), INTENT(OUT) :: EffExfilRate INTEGER (2), INTENT(INOUT) :: IFLAG END SUBROUTINE ROADWAYEXFILTRATION END INTERFACE [/fortran] I've included the library file (with full path) of the called DLL as an additional dependency to the calling DLL. I've also tried including the lib file as part of the calling DLL project - no difference. The output directories are the same (and double as the working directories, too).

Platform information
Win7 Pro
VS 2010 SP1
Composer XE 2011
Compiled for Win32

Any suggestions are welcome
Ted
0 Kudos
1 Solution
Steven_L_Intel1
Employee
541 Views
Two things. One, you omitted the ATTRIBUTES ALIAS directive from the interface visible to the caller, so the compiler did not know you renamed the routine. Also, it seems you have set the /iface:cvf option, causing the STDCALL convention to be used by default. This is ok as long as you also do that when building the DLL, but otherwise I'd suggest turning it off. If the DLL is to be called by non-Fortran, you may need to keep that on or put an explicit STDCALL in the attributes.

View solution in original post

0 Kudos
2 Replies
Steven_L_Intel1
Employee
542 Views
Two things. One, you omitted the ATTRIBUTES ALIAS directive from the interface visible to the caller, so the compiler did not know you renamed the routine. Also, it seems you have set the /iface:cvf option, causing the STDCALL convention to be used by default. This is ok as long as you also do that when building the DLL, but otherwise I'd suggest turning it off. If the DLL is to be called by non-Fortran, you may need to keep that on or put an explicit STDCALL in the attributes.
0 Kudos
Ted_Lillys
Novice
541 Views
Thanks, Steve. Added the STDCALL, REFERENCE and ALIAS attributes (because both of these DLLs get called by VB) to both the export and interface declarations and all is right with the world - compile-wise.
0 Kudos
Reply