- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After struggling with the Console write error with the latest version of IVF (documented elsewhere on this list), I have installled to 10.1.29, but the error persists. I have changed the compiler choice in Tools->Options to the version 10 compiler along with any references to libraries in the project settings.
Is there a runtime component somewhere I have to replace to get rid of this problem?
TIA
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can't find the other discussion you reference and don't recognize the problem you describe. Would you please supply more detail?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can't find the other discussion you reference and don't recognize the problem you describe. Would you please supply more detail?
Sorry, not clear enough.
It is the error writing to a console from a DLL, documented in:
Problem with Console output from a Fortran DLL | ![]() |
By larsl On December 1, 2008 10:47 AM PST
and
Error writing to console | ![]() |
By jablin@bridgetech-laramie.com On November 28, 2008 7:51 AM PST
It looks like it might be an error in the runtime libraries, since even a version compiled on 10.1.29 that works fine on the machine it was built on will generate the error when it is run on the Vista machine that had IVF 11 installed (before I installed 10.1.29 on it)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oh, this is the one where the console is created with AllocConsole. Yes, that is a run-time library error. It would show if you copied the EXE only if it was linked against the DLL form of the Intel run-time libraries. A static linked application would not show the error that way. This issue is not yet fixed - writing to unit 0 is a workaround. If you have the Fortran code in a DLL, link it statically against the old version (Properties > Fortran > Libraries > Use Run-Time Library -> Multithreaded (/MT)) and it should work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After struggling with the Console write error with the latest version of IVF (documented elsewhere on this list), I have installled to 10.1.29, but the error persists. I have changed the compiler choice in Tools->Options to the version 10 compiler along with any references to libraries in the project settings.
Is there a runtime component somewhere I have to replace to get rid of this problem?
TIA
Thanks for the tip Steve. I have naively believed that I needed to link to the DLL versions (since I was making a DLL). Linking to the static libs will also solve some support headaches.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As long as all the callers of your DLL are non-Fortran, it is safe to link the DLL statically. If Fortran code will call your DLL, then both the DLL and the caller must be linked to the DLL libraries.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
As long as all the callers of your DLL are non-Fortran, it is safe to link the DLL statically. If Fortran code will call your DLL, then both the DLL and the caller must be linked to the DLL libraries.
My calling program is a small QuickWin program (linked to the Quickwin libs). All seems to be running fine with the mixed C/Fortran DLL staticaly linked to the Fortran runtime. The entry points to the DLL are all in C.
Is this just temporary luck or is a QuickWin program really a non-Fortran program? Or does a mixed C/Fortran dll not have this limitation?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The issue is that a statically linked DLL or EXE doesn't share its run-time library with the other, so if you open a unit in one it won't be open in the other, for example. In the case of QuickWin, as long as your DLL does not try to do QuickWin operations and never allocates or deallocates memory belonging to the EXE, you're probably ok.

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