- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I have MS Access 2016 64bit and an integrated MS VS / Intel Parallel Studio XE 2020 working under Win 10 64bit. An Access application VBA code is calling a .dll Fortran program which in turn is calling an .exe Fortran program. I need to debug both the .dll and the .exe Fortran programs with or without the use of MS VS.
Said
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- In your Fortran DLL project, Debug configuration, open the project properties for the x64 configuration, select Debugging.
- Under Action > Command, set the property to the path to the Excel executable. For example, C:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
- Under Action > Command Arguments, set the property to the full path to your XLS file.
- Click OK.
- Set a breakpoint at the first executable statement in your DLL procedure.
- Make sure that the "library" you specify in the XLS is the exact path to the DLL resulting from a Debug build.
- Press F5 or Debug > Start debugging
Excel will start, and when your DLL routine is called, the debugger will stop at the breakpoint.
There is a worked example of this in the Parallel Studio XE Samples Bundle under compiler_f\MixedLanguage\Excel.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- In your Fortran DLL project, Debug configuration, open the project properties for the x64 configuration, select Debugging.
- Under Action > Command, set the property to the path to the Excel executable. For example, C:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
- Under Action > Command Arguments, set the property to the full path to your XLS file.
- Click OK.
- Set a breakpoint at the first executable statement in your DLL procedure.
- Make sure that the "library" you specify in the XLS is the exact path to the DLL resulting from a Debug build.
- Press F5 or Debug > Start debugging
Excel will start, and when your DLL routine is called, the debugger will stop at the breakpoint.
There is a worked example of this in the Parallel Studio XE Samples Bundle under compiler_f\MixedLanguage\Excel.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Steve,
I apologize for being late in responding to your message. The reason is that many programs were subject to testing and debugging and I wanted to report the result of these efforts to you.
As usual, your answer to my question is a perfect one. Yet, there is one remaining problem. The "FSEEK" statement for the sequential binary files works fine when the program is compiled by MS VS and it doesn't when compiled by ifort command line environment. To go around the problem, I replaced it by the "REWIND" statement since the purpose of the seek is to point at the beginning of the file. Do you have any idea why it doesn't work?
Said
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I assume you are referring to the FSEEK portability library function. Did you check its return value? Is your DLL the entirety of the Fortran code or do you have more than one Fortran DLL or library in the project?
REWIND is a better choice here, anyway.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Steve,
Beginning-of-file-Fseek returns "0" and because the end of the file is the current position, any Read statement after it branches to the end-of-Read routine. The .Dll program is the only one in the project. When compiling the same program by an old Intel Visual Fortran, there were no problems. The current ifort command line:
ifort /O3 /nologo /assume:buffered_io /Qinit:zero /Qinit:arrays /Qparallel /integer_size:64 /real_size:64 /double_size:64 /fpconstant /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /fpscomp:libs /module:"c:\sos\\" /object:"c:\sos\\" /libs:dll /threads /o "c:\sos\sosvoyagerprogllah.dll" "c:\sos\lib\kernel32.lib" "c:\sos\lib\imagehlp.lib" "c:\sos\lib\uuid.lib" "c:\sos\lib\ifmodintr.lib" "c:\sos\lib\ifwin.lib" "c:\sos\lib\ifconsol.lib" "c:\sos\lib\libifcoremd.lib" "c:\sos\lib\libifportmd.lib" "c:\sos\lib\libiomp5md.lib" "c:\sos\lib\libmmd.lib" "c:\sos\lib\libirc.lib" "c:\sos\lib\svml_dispmd.lib" "c:\sos\lib\libmatmul.lib" "c:\sos\lib\libcpmt.lib" "c:\sos\lib\libcmt.lib" "c:\sos\lib\msvcrt.lib" "c:\sos\sosvoyagerprogllah.f90" /DLL
is using MS VS version of:
ifmodintr.lib, ifwin.lib, ifconsol.lib, libifcoremd.lib, libifportmd.lib, libiomp5md.lib, libmmd.lib, libirc.lib, svml_dispmd.lib, libmatmul.lib, and msvcrt.lib.
Said
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That looks ok to me. I have no idea what the difference might be.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A good guess at the problem is the (implicit) folder used in the OPEN statement is .NOT. that which you expect it to be. IOW you may have created/used a file elsewhere from what you think it is (same name, different folder)
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim,
So long since our last messages.
No such case. The strange thing is that the same program when compiled by MS VS it runs without problems. Same thing when it was compiled with old Intel-Visual-Fortran command line. My guess is that VS is using consistent set of libraries while I'm not doing the same thing in the ifort command line. Do you have any idea what libraries have to do with Fseek? Do you think libraries such as libcmt.lib and libcpmt.lib are responsible?
Said
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Do you have USE IFPORT in the procedure that calls FSEEK? If not, you may be getting the wrong one.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Steve,
Do you think MS VS has used IFPORT by itself when compiling the same program and runs it successfully?
Said
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No. It would be interesting to see the build output when the linker option /verbose is specified. From the command line, add "/link /verbose" to the end of the ifort command that does the link. In VS, set project property Linker > General > Show progress to "Display all progress messages" and then do a build. Zip the buildlog.htm from the VS build and capture the command output (you may need to redirect the output - use " > log.txt" at the very end of the ifort line) and attach to a reply here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Steve,
For command line, using " > log.txt" was not successful. Therefore there was no way but to capture 51 images. Some images are large and some are small !!. Attached herewith please try to view them plus the MS VS build log. For notification, the program compiled by VS does not contain "use IFPORT" while the one compiled by the ifort-command-line contains it.
Said
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks - both builds are using the same FSEEK. I am out of ideas for now.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Steve,
Thank you for your professional support. I'm lucky your are still there.
Said
![](/skins/images/872293744008A34B36F8ABF94A46CC66/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page