Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
1 View

Using GETENV without USE IFPORT

Jump to solution

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

Accepted Solutions
Highlighted
Black Belt
1 View

There is no mystery here. You

Jump to solution

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
Highlighted
Black Belt
2 Views

There is no mystery here. You

Jump to solution

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
Highlighted
1 View

Thanks mecej4.  All this

Jump to solution

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