PSA: Update the Runtime Library when you update the compiler!

[Steve_Lionel]

Beginning with the oneAPI series of compilers, Intel stopped including the runtime library with the compiler installer and doesn't warn you that you need to install it separately. This can lead to errors when running programs linked to DLL libraries outside of Visual Studio. (I'm unclear as to how this works on Linux, but the advice remains.)

To download the runtime installer:

1. Go to Intel® oneAPI standalone component installation files
2. In the left column, select Runtime Versions
3. Select your operating system
4. For Linux, follow the instructions shown. For Windows and MacOS, download and run/install the Intel Fortran Compiler Runtime.

If you provide your application to others, have them follow these instructions as well. You need only the latest version - it will work with older compiler versions.

[avinashs]

@Steve_Lionel Thanks for the important reminder. A couple of questions:

1. Do these runtime files have to be updated along with every compiler update as well?

2. If a .dll has been built with the compiler option /libs:static and the exported functions have been built with the directive !DEC$ ATTRIBUTES DLLEXPORT, STDCALL, REFERENCE, ALIAS : 'my_dll' :: my_dll, do the runtime files have to be distributed to other users along with the .dll? This was not required in the past with these options. One of the reasons for asking is the fact that internal users of the .dll within the company do not have the admin rights to install any software, hence the above method proved suitable to have one .dll distributed that could be put on the "allowed list" by IT.

[Steve_Lionel]

Have to be? It depends. If the compiler starts using a new entry point, you'll need them. Updating the libraries also gets you bug fixes, without which you might still be seeing a problem claimed to be fixed.

Please do not produce DLLs that are linked statically unless you KNOW that the user won't be using Fortran themselves. Otherwise, you end up with two copies of the libraries and that can create difficult-to-analyze problems. Also, there are some Intel Fortran features not available except with the DLL libraries.

IT is already used to installing MSVC redsistributables, without which most Visual C++ applications won't work.

Intel used to provide "merge modules" that can be included in your own installer to install the redistributables. I don't think these are available now. (Another user-hostile move.)

[DavidWhite]

I've always used this method too, to distribute DLL applications, e.g. for use by Excel users.  It is useful to include all runtime libraries within the DLL to ensure that the correct version is in use, in addition to avoiding the installation issues @avinashs mentions.

It would be a significant hurdle if users of generated applications need to install the correct runtime library for each version of the app (I had over 500 users across multiple locations and time zones, so getting the IT people to understand the need for extra installs would be a burden). 

[Steve_Lionel]

If your DLL is being used from Excel, then static linking is fine. It's when it's used from a Fortran program that things go off the rails.

[DavidWhite]

Do you mean if the Main Fortran program and the DLL are using different runtime libraries?

[mecej4]

Here is an example where a program calls one subroutine located in a DLL and another subroutine that is within the EXE itself. Both subroutines write to a text file that was opened in the main program before the subroutines were called.

program twoface
implicit none
open(11,file='output.txt',status='replace')
call sub1()
!
call sub2()
close(11)
end program

subroutine sub1()
implicit none
integer i
write(11,'(2i5)')(i,2*i+1,i=1,9,2)
return
end subroutine

subroutine sub2()
implicit none
integer i
write(11,'(2i5)')(i,2*i+1,i=2,10,2)
return
end subroutine

I put the main program code into twoface.f90, and the subroutines into sub1.f90 and sub2.f90, and built the DLL and the program as follows.

ifort /LD /Od sub2.f90 /link /export:SUB2
ifort /Od twoface.f90 sub1.f90 sub2.lib

Note that  the main program and SUB1 use the statically linked Fortran libraries, whereas SUB2 is linked to the DLL libraries. Even though the static and dynamic libraries are from the current OneAPI release, the two libraries run in two different contexts. I/O unit 11 in one RTL is different from I/O unit 11 in the other RTL. Extrapolate this observation to what can happen in a complex application with hundreds of subroutine calls with libraries from several sources.

Running the program creates two files: 

• File "output.txt" with the output from SUB1
• File "fort.11" with the output from SUB2

This is one of the problems about which Steve_Lionel cautioned.

[Steve_Lionel]

Two copies of the libraries that don't talk to each other. Can cause I/O problems, errors in allocate/deallocate, more.

[DavidWhite]

The latest 2022.1 runtime does not appear to be available -- only showing 2022.0 on the download page.

[Barbara_P_Intel]

These version numbers are driving us all a bit crazy.  At the Toolkit level the version is 2022.1.  But at the component level, and the runtimes are at the component level, the version is 2022.0.  That includes runtimes for both the Fortran Compiler and the Fortran Compiler Classic.

[DavidWhite]

and to make it harder to check, the embedded file and product versions in the DLL's are, e.g. 20.0.1.0

[Devorah_H_Intel · Accepted solution]

To clarify: 

When installing the entire oneAPI HPC toolkit (not stand alone compiler) - latest runtimes are included in the following directories: 

C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\redist\intel64_win\compiler;

C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\redist\ia32_win\compiler

These directories are included in PATH.  

Here is an example of my PATH output in generic CLI after installing oneAPI HPC Toolkit 2022:

>set PATH
Path=C:\Program Files (x86)\Intel\oneAPI\mpi\latest\bin\;C:\Program Files (x86)\Intel\oneAPI\mpi\latest\bin\release\;C:\Program Files (x86)\Intel\oneAPI\mpi\latest\libfabric\bin\;C:\Program Files (x86)\Intel\oneAPI\mpi\latest\libfabric\bin\utils\;C:\Program Files (x86)\Intel\oneAPI\tbb\latest\redist\intel64\vc_mt\;C:\Program Files (x86)\Intel\oneAPI\tbb\latest\redist\ia32\vc_mt\;C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\redist\intel64_win\compiler;C:\Program Files (x86)\Intel\oneAPI\compiler\latest\windows\redist\ia32_win\compiler;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\Program Files (x86)\F-Secure\ssh;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\;C:\Python36;C:\Program Files (x86)\IntelSWTools\system_studio_2020\tools\DAL_1.2012.1214.110\;C:\Program Files\PuTTY\;C:\Users\dhayman\AppData\Local\Microsoft\WindowsApps;C:\Users\dhayman\AppData\Local\GitHubDesktop\bin;
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC

[JohnNichols]

The MKL 32 bit libraries are not included with oneapi. In the mkl Forum, @mecej4 has provided a link to download them, I could not find them, but the link works. 

If you have old MKL programs you may need the libraries otherwise you get weird errors of no known human origin.  

The new numbers make as much sense as the statement that Richard Feynman had a measured IQ of 120, which is oft quoted, it only proves that IQ is relative.  

 “You’re unlikely to discover something new without a lot of practice on old stuff, but further, you should get a heck of a lot of fun out of working out funny relations and interesting things.”

— Richard P. Feynman.

[Devorah_H_Intel]

MKL Release Notes state that 32bit MKL is available at this link https://www.intel.com/content/www/us/en/developer/articles/tool/oneapi-standalone-components.html#inpage-nav-9-7 

very few customers use 32bit MKL so they are not included with oneAPI Base toolkit which contains MKL 64bit. 

(this is a different case of stand-alone performance library - nothing to do with runtimes which in fact, are included with oneAPI HPC toolkit -both 64bit and 32bit as I pointed out above)

[Steve_Lionel]

It's recent behavior that the "latest" folders are added to PATH.  If that's now the case, (and it is on my system), then this thread isn't necessary. We had lots of complaints here on the forum that programs would not run outside of the build environment or VS in the past.

[Devorah_H_Intel]

Thank you, Steve, for confirming. I missed this thread as I was out due to covid (I am OK now), otherwise, I would have posted earlier. This change to the PATH was implemented a couple of releases ago as a solution in response to the earlier (in Spring) issue of missing runtimes, as you correctly noticed. We will just "un-float" this topic while keeping the discussion.