- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page