Visual Fortran run-time error with Release compile, not with Debug

[dan_hensley]

Hi, I am evaluating the new XE compiler while I'm waiting for our licenses to be installed. I have Fortran code compiled into a DLL (originally from version 9.1, just upgraded to XE). I call one entry function in this DLL from another one written in C++ that I am compiling with VS2008sp1. When I link to the Debug version of the Fortran DLL, all works well. However, when I link to the Release version, I get

forrtl: severe (38): error during write, unit 6, file CONOUT$

...

libifcoremd.dll 0D7518FA

libifcoremd.dll 0D74B778

libifcoremd.dll 0D6CC000

...

Any ideas why this is happening?

[Steven_L_Intel1]

My guess is that you've got an old version of LIBIFCOREMD.DLL in PATH. Use Dependency Walker to identify the full path to each DLL being loaded.

For a short time in 11.0, writes to a console output unit when there was no console would get this error. Previously, such writes were ignored. Enough people had written programs that did this odd thing that we reversed the change in 11.1.

Where do you expect those writes to go?

[dan_hensley]

Thanks for the quick reply. My Fortran code opens unit 6 for writing to a file. It turns out that there were a few writes that happened before this redirect. I recompiled with the redirect happening first, but that didn't fix the problem. I'm not sure where console writes would go, because the application that calls my DLL which calls the Fortran DLL redirect it to who-knows-where.

The dependency walker I think explains why the release version behaves differently from the debug. It's loading version11.1.5.5 of LIBIFCOREMD.DLL, which comes from the main application. I try to force my path to find the XE versions, but for some reason that doesn't appear to work.

Is there anything else I can do with my code to get around the crash?

[Steven_L_Intel1]

If the EXE has a copy of LIBIFCOREMD.DLL in its folder, remove or rename that file. Or you can link your DLL statically (Fortran > Libraries > Use Runtime Library > Multithreaded) and remove the dependency on the Intel (and Microsoft) DLLs. As long as the EXE calling your DLL is not Fortran, this is safe.

[dan_hensley]

I'll try the static linking. Although that might not be safe, because I know that the EXE does use FORTRAN in its core. I can't rename the DLL in its folder because the EXEprobably uses it (maybe that's why my path modifications didn't work?). I'll keep hacking at this now that I know what the basic issue is. It's strange though that the redirect to file still shows this problem.

Dan

[dan_hensley]

Follow-up to my reply. I put the Libifcoremd.dll from Fortran XE into my working directory and confirmed that it is being loaded by my DLL, and I still get the same crash.

[Steven_L_Intel1]

Do you still think you have unit 6 opened to a file? Because the CONOUT$ suggests otherwise. What happens if you link your DLL statically? Is the EXE Fortran or something else?

[dan_hensley]

I tried compiling statically, and got hundreds of compile errors (multiply defined symbols, etc.). So unfortunately it looks like this approach isn't going to work. Compiling as debug DLL did work, because it's then looking for LIBIFCOREMDD.DLL. Any idea why the debug version of this library works but the release doesn't?

[dan_hensley]

Oh, the pain. I found a few places where it was writing to a variable supposedly set to 6, but it wasn't. I found a few places using print instead of write, and one where the variable wasn't defined as an integer. After cleaning all those up, I got it working. The vast majority of the Fortran code is 20 year old F77 code that I inherited and ported from HP-UX. I'm surprised this didn't show up before.

At any rate, on to the next issue.

Thanks for all your help, and thank God for tracebacks.

[Steven_L_Intel1]

Glad to hear it.