Using both IVF11 under Visual Studio 2008 and Intel Fortran Composer XE 2016 under Visual Studio 2015 on one PC

[Jaap_G_]

Since a month now I have both IVF11 running under VS2008 and IVF16 under VS2015 on my PC. After some installation problem with IVF16 and rebuilts of my application I have encountered a problem that deals with finding the right location of the dll's that are used.

When installing IVF16 it removes IVF11 settings :-( This can be solved by reinstalling IFV11 but this overrules the settings for IVF16. I am talking about the PATH environment variable that is used for both IVF11 and IVF16. After reinstalling IVF11 IVF16 cannot find the dll's that belong to IVF16. It looks for the dll's in the IVF11 directories...

This is a problem when Fortran is mixed with C/C++. The C/C++ application is looking for the dll's in the wrong directory. Setting the VC++ directories does not solve problem. It can only be solved by explicitly setting the PATH environment variable when debugging.

So question would be: how can I mix both IVF11 and IVF16 on one PC that automatically use the correct Fortran dll's?

[TimP]

You must avoid depending on paths added during compiler installation to the shared Windows paths. If the (old) installer asks whether to modify those paths, say no.  You may have to clear those paths manually using Windows own editor and restart.  Then you rely on the paths set up within Visual Studio or by opening the cmd prompt windows for each individual compiler, which take care of running the compilervars.bat and associated vsvars.bat.

[Steven_L_Intel1]

This is mostly covered by https://software.intel.com/en-us/articles/using-older-intel-visual-fortran-versions-in-different-microsoft-visual-studio-versions  The DLLs are not an issue - you'll always be using the latest ones (assuming you link to the DLLs) and that is preferable.

[TimP]

I just went through the exercise of rotating among 15.0.6, 16.0.3, and 17.0 by referring to the article Steve linked to.  I've got questions still about why one of those is more stable in GUI than when run from command line, another less so.  Did my best to check the GUI build log and try the same options from command line.  I still wonder if it has something to do with which dll are on PATH.

[Jaap_G_]

Thanks four your answer. I guess Tim is right about clearing the PATH variable from everything pointing to Fortran directories. When you don't do this and you have the newer compiler installed the PATH variable is modified resulting in:

%INTEL_DEV_REDIST%redist\intel64_win\mpirt;%INTEL_DEV_REDIST%redist\ia32_win\mpirt;%INTEL_DEV_REDIST%redist\intel64_win\compiler;%INTEL_DEV_REDIST%redist\ia32_win\compiler;%IFORT_COMPILER11%lib\Intel64;%IFORT_COMPILER11%lib\ia32;%IFORT_COMPILER11%mkl\em64t\bin;....

This will result in VS2008 + IVF11 using the IVF16 dll's. This does not work.

If you change the PATH variable by moving the IVF11 settings in front of the IVF16 settings VS2008 + IVF11 works fine but VS2015 + IVF16 will use the IVF11 dll's. which may result in a less stable application.

The article mentioning using older compilers is correct as long as you are using IVF14 or less. IVF14 or less can be used in VS2008. So you can choose which compiler to use. IVF15 or higher cannot be used in VS2008. IVF11 can only be used in VS2005 and VS2008, not in VS2015.

What Steve mentions about always using the correct dll's may be true when only using Fortran. Not when calling Fortran from C/C++. May be Steve  can tell more about this?

[Steven_L_Intel1]

Intel Fortran runtime DLLs are upward-compatible. It is always best to use the most recent.  But C++ is different. For many releases now, including VS2008, Microsoft uses "shared assemblies" that have the version encoded into the name so that you get the right version, regardless of PATH.

It is not clear to me exactly what problem you're running into. "Does not work" is not enlightening.

The article is correct, but it does not say you can use any compiler version in any VS version. The first paragraph links to another article that lists the supported combinations.

[Jaap_G_]

I'm confused by the fact that the dll's are upwards compatible and saying at same time to use the most recent version which would imply a downwards compatibility. After all in the latter case the newer dll's (that are supposed to be better) still can run with older applications. I guess what you mean is that the functionality in the IVF11 dll's is also in the IVF16 dll's.

The problem I'm running into is that I when I use the latest IVF16 dll's in VS2008 I get an error "Entry point not found", the procedure entry point ISO_C_BINDING_mp_C_ASSOCIATED_PTR could not be located in the dynamic link library libifcoremdd.dll. So I'm using the most recent dll's in VS2008.

The other way around: When I tell VS2015 to use the IVF11 dll's my application is running fine (in VS2015)'. this would explain the upwards compatibility.

[Steven_L_Intel1]

When I say "upward compatible" I mean that you can use a Fortran DLL newer than the compiler used to build the application.

Your error indicates you are using older run-time DLLs somehow. Unless you added something, or PATH contains old entries, this should not happen. Check your PATH environment variable and make sure it has only the %INTEL_DEV_REDIST% entries.

[Jaap_G_]

I have checked the PATH environment and it contains only  %INTEL_DEV_REDIST% entries. Everything works fine in VS2015 + IVF16.

When I try to run the same project in VS2008 + IVF11 I get the error. VS2008 is using the same PATH variable (I wouldn't load other important dll's if I hadn't the PATH variable). I can see the correct (i.e. IFV16) dll's being loaded in VS2008:

'RFMSd.exe': Loaded 'C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler\libifcoremdd.dll', Binary was not built with debug information.

'RFMSd.exe': Loaded 'C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler\libmmd.dll', Symbols loaded (source information stripped).

Only when I add extra environment variables to the debugging properties (pointing to the IVF11 dll's) the application it works fine. And that is what I am doing right now to work around the problem ;-)