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

Using GETENV without USE IFPORT

NotThatItMatters
Beginner
420 Views

Okay, I know this has been hashed through with the USE DFPORT possibility, but I just compiled up my code which had been using IFPORT and found some really weird results without USE IFPORT.  The idea was to compile the app I have using strictly USE ***, ONLY clauses.  The app is a QuickWin application with a few Windows API calls interspersed and the getting of an environment variable on the front end.

Diligently I went through the code and found clauses along the lines of

USE Strawberry

and commented them out.  I then let the VS compiler/linker catch all my missing references.  The code is compiled with IMPLICIT NONE everywhere.  In doing this the compiler/linker never found the missing reference to GETENV.  Thus it was not "missing" at all, but I am unsure what it found because it certainly did not work.  The program hung very early in the INITIALSETTINGS call (QuickWin) and never pulled its way out.  Very strange.

0 Kudos
1 Solution
mecej4
Honored Contributor III
420 Views

There is no mystery here. You called the routine GETENV(), which is provided by, e.g., libifportMD.lib/libifportMD.dll with two strings as arguments. That call happens to have the correct interface, so everything works without your having a USE PORTLIB statement. The following example code from the IFort documentation does something similar:

program gete
implicit none
character*40 libname
CALL GETENV ("LIB",libname)
TYPE *, "The LIB variable points to ",libname
end program

Generating a map file and inspecting it shows where the routine was found. You can also use the linker /verbose option, and you would see

Starting pass 1
Processed /DEFAULTLIB:ifconsol
Processed /DEFAULTLIB:libifcoremd
Processed /DEFAULTLIB:libifportmd
Processed /DEFAULTLIB:libmmd
Processed /DEFAULTLIB:MSVCRT
Processed /DEFAULTLIB:libirc
Processed /DEFAULTLIB:svml_dispmd
Processed /DEFAULTLIB:OLDNAMES

Thus, a number of libraries are searched for any Fortran build even though not one of those libraries was specified explicitly.

View solution in original post

0 Kudos
2 Replies
mecej4
Honored Contributor III
421 Views

There is no mystery here. You called the routine GETENV(), which is provided by, e.g., libifportMD.lib/libifportMD.dll with two strings as arguments. That call happens to have the correct interface, so everything works without your having a USE PORTLIB statement. The following example code from the IFort documentation does something similar:

program gete
implicit none
character*40 libname
CALL GETENV ("LIB",libname)
TYPE *, "The LIB variable points to ",libname
end program

Generating a map file and inspecting it shows where the routine was found. You can also use the linker /verbose option, and you would see

Starting pass 1
Processed /DEFAULTLIB:ifconsol
Processed /DEFAULTLIB:libifcoremd
Processed /DEFAULTLIB:libifportmd
Processed /DEFAULTLIB:libmmd
Processed /DEFAULTLIB:MSVCRT
Processed /DEFAULTLIB:libirc
Processed /DEFAULTLIB:svml_dispmd
Processed /DEFAULTLIB:OLDNAMES

Thus, a number of libraries are searched for any Fortran build even though not one of those libraries was specified explicitly.

0 Kudos
NotThatItMatters
Beginner
420 Views

Thanks mecej4.  All this ensued because of a small discrepancy between code in a straight ahead routine and the identical code in a MODULE.  I thought the module would have very little effect on the output if any at all.  Being as the call occurred during initialization and the lsb changes which happened propagated down, the results were notably different.  This is the definition of chaos.

Anyway, I had not realized the calls I was using were found in other libraries because my search on documentation yielded so few results.  I must learn how to read.  Consider this one closed.

0 Kudos
Reply