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

error LNK2019: unresolved external symbol _GETENV@16 referenced in function _OPENFL

Wagner__Urs
Novice
2,552 Views

Hello

My application is using STDCALL references.

How must I fix the upper error?

1>SETUP.obj : error LNK2019: unresolved external symbol _GETENV@16 referenced in function _OPENFL
1>Debug/KRXPC.exe : fatal error LNK1120: 1 unresolved externals

 

I am using

USE IFPORT

and LIBIFPORT.LIB

as additional libraries.

 

Thanks.

0 Kudos
22 Replies
mecej4
Honored Contributor III
248 Views

I get the impression that NIST expects very few users of Refprop to call it from Fortran.

I have only seen an older (2017) version of the source file that you mentioned, PASS_FTN.FOR, and it contains the following comment:

This file defines the DLL-callable routines that are used by c Visual Basic, Excel, and other applications to access the main c Fortran code.It is not needed when compiling Fortran applications. It is only used when compiling the DLL.

In one of Wagner_Urs's posts in this thread, we were told, "I try to use a stand alone with the fortran code."

I do not know which version of Refprop was used by Wagner_Urs, but this comment may apply to that version, as well. In a Fortran driver that is compiled with all the source files of the Refprop package, the file PASS_FTN.FOR is not needed at all, and the calls to the Refprop routines may be as follows:

 

 

      call REFPROP ('c:\ENGR\REFPROP10\FLUIDS',
      call SETFLUIDS ('ethane;propane;isobutan;butane',ierr)
      call ERRMSG (ierr,herr)   

 

 

That is, with no "dll" appended to each subroutine name, and no role for the source file PASS_FTN.FOR with its non-standard interfaces.

Wagner_Urs mentioned using /iface:cvf, but that was not necessary.

0 Kudos
Hitoshi
Novice
241 Views

merce4

Yes I fully agree with your recommendation. Thank you  for additional comment.
As also recommended in GitHub discussions, using REFPROP routine directly from REFPROP Fortran subroutine sources is easiest and reliable way.
Users can also add user-original module files to avoid troublesome many arguments lists, though well-understanding of each arguments is necessary .

Reply