LUNS in DLLS

[Intel_C_Intel]

We have a PC application that uses a FORTRAN DLL we have written. This DLL uses math routines in a third party DLL. In our DLL we OPEN a diagnostic output file on LUN 6, and pass this LUN to the third party DLL to catch their diagnostic output.

Though this worked fine when we were able to statically link the third party code (no longer possible for licensing reasons), it is unreliable when using the DLLs (it keeps crashing in the FORTRAN runtime DLL with severe error 38 (error with WRITE) when writing to unit 6 file $CONOUT (it also occasionally tries to write to unit 0)).

It appears as though the third party DLL does not have access to the file through the lun opened in out DLL. If we change our lun number to (say) 8, our diagnostic messages appear in the diagnostic file we open but the third party diagnostic messages appear in a file 'fort.8' generated by the FORTRAN runtime in the current working directory (a standard FORTRAN response I believe).

Is this a FORTRAN problem, or (more likely) a problem with our third party DLLs?

[Steven_L_Intel1]

The problem is that one or more of the DLLs, and/or the executable, are not linked against the DLL form of the CVF run-time libraries. This is required for each DLL to be referring to the same LUNs.

Steve

[Intel_C_Intel]

OK - thanks Steve.

All our stuff consistently uses the single-threaded DLL run-times, the 3rd party DLL shows nothing on 'View Dependencies' suggesting a static link against whatever they compile with.

Looks like we have no option but to push all our diagnostics through the third party DLL (so it controls the LUN). Its possible, but I was hoping I could avoid the necessary recoding.