Incompatible versions of the libifcore.dll

[A__Valle]

Dear all,

I am developing a plugin for a 3rd party flowsheeter. Our software is shipped with the version 13.1 of the redistributable libraries. In the installation of the flowsheeter, an older version of the libifcore.dll is put in c:\Windows\System32\.

When trying to load our plugin, an error message is spawned that we are trying to load an incompatible version of the libifcore.dll. Our software is not compatible with these older version and we are depending on the MKL, making static linking (what we did before) not possible.

Can I just replace the older redistributables with the newer ones, i.e. are they backwards compatible? Or is there another solution to this problem.

Thanks for all your help

Dirk van Meeuwen

[TimP]

In the past, we've been informed that the .dll are tested for compatibility with the previous major version, so 13.0 .dll would work with 12.0 objects.  Usually, the compatibility would extend further.  I don't know that there will be a 13.1 compiler, although the numbering of the updates seems to have been intentionally confusing.

It's generally been advised not to put Intel compiler support .dll in Windows system folders, largely because of such version problems.  I guess this wasn't your decision.

I would have thought static linking of MKL would be possible (following the MKL link advisor), aside from dependence on OpenMP library in the case where you use the MKL threaded.

[A__Valle]

Tim,

Thanks, for the answer. The installation in windows system folders is indeed from the third party. We are obliged to work with them under their conditions. This was indeed the reason for the question if I can replace these specific dll's.

Do you know of any incompatibilities between the 10.0 objects and the 13.0 objects?

We did remove the static linking due to the use of OpenMP within MKL, according to: http://software.intel.com/en-us/articles/openmp-static-library-deprecation-in-intelr-mkl-on-microsoft-windows

Dirk

[Anonymous66]

The following incompatibilites exist between 10.0 and the current version, 13.1:

1. Sources that use the CLASS keyword to declare polymorphic variables and which were built with a compiler version earlier than 12.0 must be recompiled.
2. Objects built with the multi-file interprocedural optimization (/Qipo) option must be recompiled.
3. Objects that use the REAL(16) , REAL*16, COMPLEX(16) or COMPLEX*32 datatypes and which were compiled with versions earlier than 12.0 must be recompiled.

If none of these conditions apply to the 10.0 code, then you can upgrade the .dlls safely.

[IanH]

(I'd expect that object code (stuff that is yet to be linked) might be a bit more stringent in its backward compatibility requirements than fortran runtime library client executable images (stuff that has already been linked to an exe or DLL) - with the fortran runtime if you make a breaking change Intel could always rename the relevant runtime helper function and provide the new one in parallel with the old one.)

It has been a while, but I have had issues in the past with a chemical plant flowsheet process simulator (Aspen Plus) popping old ifort DLL's (and they were perhaps about the ifort version 10.0 era) in the system32 folder.  It rendered my computer unusable for development with Intel Fortran.  I swore a lot, then simply (but carefully) obliterated the relevant ifort DLL's from the system folder (DLLs that had the same name as the current runtime DLLs) and carried on (the runtime libs for current compiler versions were installed in the usual place via the Intel msi). 

Similarly, Matlab installations had a habit of whacking their entry at the front of the PATH - this can similarly cut-off the Intel runtime DLL installation.  Same fix (though editing the PATH would also be an option).

[TimP]

Next release looks like breaking backward compatibility with object files.  No official word, just test results.