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

Calling a Function in a dll

Schwandt__Olaf
Beginner
266 Views

Hi Steve, hi all,

 

I have a third party DLL, wich I use as a resource.

Calling a Subroutine from this dll is not a problem, e.g.

s o u r c e:

Subroutine CallTypeExt(SimTime,CurIter,UnitNum,TypeNum,Ins,Outs,Ts,DTDTs,Pars,OverallIter,iCnt,iConverge,NumOut,NumCont)
 !Dec$ Attributes DLLexport :: CallTypeExt

m y  u s e:

call CallTypeExt(DxTime,CurIter,Unit_nr,Type_nr,xIn,xOut,T,DTDT,xPar,OverallIter,iCnt,iConverge,NumOut,NumCont)

 

but a Function (from the same routine of my program) I'm not able to use:

s o u r c e:

Function getTrnsysRootDir()
 !dec$ attributes dllexport :: getTrnsysRootDir
 !d!ec$ attributes dllexport, c, reference, nomixed_str_len_arg :: getTrnsysRootDir
 !d!ec$ attributes alias:"TRNSYSFUNCTIONS_mp_GETTRNSYSROOTDIR", decorate :: getTrnsysRootDir

m y  u s e (j u s t   a   t r y):

xStr=TRNSYSFUNCTIONS_mp_GETTRNSYSROOTDIR()

while compiling and linking there comes the error LNK2019 and LNK120: unresolved external symbol "_GETTRNSYSUSERLIBDIR"

(the source I have from the company who made the whole dll. but there is much more insight the dll (what I don't have), so I must use that dll)

 

Would you help me: how can I use that Function correctly? Do I need a module definition or some attributes in my routine?

thank you in advance

 

regards

Olaf

 

0 Kudos
1 Reply
Lorri_M_Intel
Employee
266 Views

Lots of interesting things here.

First, I assume there is some sort of cut-and-paste error here, since the external name in the error message ends with "userlibdir" and the declaration you showed ends in "rootdir"

That said, the function you show  seems to be a module procedure.   Didn't the 3rd party ship a module file?   That way you could simply "use" the mod file, and the external declaration will be available, and life would be simpler.

Next, if you do not have the module file and have to go through this interface mechanism,  the way you would invoke the function would be to use the function name, getTrnsysRootDir, rather than the external alias name.

The call would be

     xStr = gettrnsysrootdir

Finally, are you sure the interface is correct?   I'm curious about this line (which does seem to have an extra "!" in it):

!d!ec$ attributes dllexport, c, reference, nomixed_str_len_arg :: getTrnsysRootDir

I would not expect this routine to have "C" attributes.   Good news is that the typo means this line is ignored :)

                             --Lorri

 

0 Kudos
Reply