- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm experiencing unexpected behavior when using fortran formatted output to a text file from within my fortran DLL. Details below.
I have some subroutines that perform formatted fortran output to a particular unit number opened in the calling program. When those subroutines are included in the main program source file and compiled/linked, the i/o works as intended. When the i/o subroutines are linked as a DLL (no code changes), the output to the text file is truncated. I have verified that the write statements are executed properly by redirecting output for that unit number to stdout (conout$). The problem only seems to exist when trying to write that information to a file.
Please help.
Thanks.
I have some subroutines that perform formatted fortran output to a particular unit number opened in the calling program. When those subroutines are included in the main program source file and compiled/linked, the i/o works as intended. When the i/o subroutines are linked as a DLL (no code changes), the output to the text file is truncated. I have verified that the write statements are executed properly by redirecting output for that unit number to stdout (conout$). The problem only seems to exist when trying to write that information to a file.
Please help.
Thanks.
Link Copied
10 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The calling program needs to be linked against the DLL version of the runtime library, as in /libs:dll.
James
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried this and still have the problem.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If you can reduce your problem to a small sample then try posting it. Otherwise you can try to do an INQUIRE inside your DLL routine on the unit to see if it is open already or not. The reason for using /libs:dll was to ensure that you are using the same version of the RTL in both the DLL (where using the /libs:dll is default if building from VS) and the main program (where using /libs:dll is not the default), otherwise what would essentially be happening is the DLL would be doing I/O to that unit ever formally opening the unit from its point-of-view. In that case I would expect an INQUIRE would show that the unit is closed prior to doing the first WRITE.
James
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the help.
Turns out the /libs:dll compiler option did solve the problem. I forgot to use that option for my executable the first go-round.
Turns out the /libs:dll compiler option did solve the problem. I forgot to use that option for my executable the first go-round.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am using CVF6.6. In the main program,I open file unit 10 and append some text within dll to the same unit 10, but there are two files generated and fort.10 is obviously from dll.
How can I set continuity of I/O between code residing in a main program and code residing in a DLL?
I tried several times in project->setting->link by adding /libs:dll, no improve abtained.
I really appreciate your kind help.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you make this change for the executable project? Make sure that the libraries setting for both is DLL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
I am having a similar problem to this thread. dll writing output to fort.2000 rather than already opened unit 2000. This is with visual studio 2005, ifort 10.0.3847. I have tried several combinations of the runtime library options (/libs), always keeping executable and dll projects the same to no avail. I also still use cvf when I can, and in that, if the runtime library linking is misaligned, I get the same behavior as I am getting with ifort, but, when the runtime library linking is aligned, it works correctly.
Thanks
I am having a similar problem to this thread. dll writing output to fort.2000 rather than already opened unit 2000. This is with visual studio 2005, ifort 10.0.3847. I have tried several combinations of the runtime library options (/libs), always keeping executable and dll projects the same to no avail. I also still use cvf when I can, and in that, if the runtime library linking is misaligned, I get the same behavior as I am getting with ifort, but, when the runtime library linking is aligned, it works correctly.
Thanks
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
All I can say is that if the use of DLLs is consistent, then it should work. How about this - download Dependency Walker, run it, drag your executable onto it, do a File > Save of the information and attach the .dwi file to a reply here. What you want to look for is both the EXE and the DLL referencing the same libifcoremd.dll.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for your reply.
I was telling it to ignore libifcoremdd.lib (ignore specific library) because I was getting severall of the following type of link errors:
Error 4 error LNK2005: _for_emit_diagnostic already defined in libifcoremdd.lib(libifcoremdd.dll) libifcoremt.lib
Also ignored MSVCRTD.lib because of:
Error 15 error LNK2005: _exit already defined in MSVCRTD.lib(MSVCR80D.dll) LIBCMTD.lib
Ignoring both of these allowed it to link and run, but I got the issue with the writing to the unit. I tried ignoring just MSVCRTD.lib, and it links, but then I get a stack overflow at a call to a subroutine with no arguments.
I also have a static library (mix of C and fortran) that is included in the executable project - is this why I am getting these "already defined" errors? I did not think the settings used to build the static library mattered, and, is it even proper to use /libs:dll when builing a static library?
Thanks very much for your help ... saw some of your blog discussing New Hampshire - I used to live in Portsmouth and I really miss it.
I was telling it to ignore libifcoremdd.lib (ignore specific library) because I was getting severall of the following type of link errors:
Error 4 error LNK2005: _for_emit_diagnostic already defined in libifcoremdd.lib(libifcoremdd.dll) libifcoremt.lib
Also ignored MSVCRTD.lib because of:
Error 15 error LNK2005: _exit already defined in MSVCRTD.lib(MSVCR80D.dll) LIBCMTD.lib
Ignoring both of these allowed it to link and run, but I got the issue with the writing to the unit. I tried ignoring just MSVCRTD.lib, and it links, but then I get a stack overflow at a call to a subroutine with no arguments.
I also have a static library (mix of C and fortran) that is included in the executable project - is this why I am getting these "already defined" errors? I did not think the settings used to build the static library mattered, and, is it even proper to use /libs:dll when builing a static library?
Thanks very much for your help ... saw some of your blog discussing New Hampshire - I used to live in Portsmouth and I really miss it.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
What this tells me is that you do NOT have all the projects set to the same set of libraries. Yes, how you have static libraries built matters too. Make sure the setting is consistent across all the projects, including C, and that they are ALL referencing the same set of DLL libraries (either all debug or none debug.) Don't have any that reference static libraries.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page