setvars.bat broken in OneAPI 2024.0

SP_Van · ‎03-05-2024

Brand new installation of OneAPI Base and HPC Toolkits 2024.0. Integrated with VS2022. setvars.bat assumes a directory structure for Intel/OneAPI/... but it does not correspond to the actual installed directory structure. It seems to complete but does not set up paths correctly. ifort at the command prompt is not recognised. i can manually add a path for the correct compiler directory but am still getting linker errors.

Code compiles OK inside VS2022 but does not run with missing library errors, e.g. libifcoremd.dll not found.

Help will be very welcome.

Steve_Lionel · ‎03-06-2024

The directory structure did change, but your problem may be that the installation doesn't set the system environment variables correctly. I hope this gets fixed in the next update.

Check to make sure that:

IFORT_COMPILER24 is set to C:\Program Files (x86)\Intel\oneAPI\compiler\latest\

and that PATH contains:

C:\Program Files (x86)\Intel\oneAPI\compiler\latest\bin

and

C:\Program Files (x86)\Intel\oneAPI\compiler\latest\bin32

SP_Van · ‎03-06-2024

Hi Steve,

Thanks for the quick response. The installed directory structure does not have a /latest/... subdirectory (probably because this is a completely fresh install with no previous instances of oneAPI). Here is an edited version of the installed directory tree...

D:\Intel

└───oneAPI

├───advisor

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin32

│ │ ├───1033

│ │ ├───gtpin

│ │ └───runtime

│ ├───bin64

│ │ ├───gtpin

│ │ ├───locales

│ │ ├───runtime

│ │ └───swiftshader

... other subdirectories removed for clarity

├───basekit

│ └───2024.0

│ └───.toolkit_linking_tool

├───common

│ └───2024.0

│ └───.toolkit_linking_tool

├───compiler

│ ├───2024.0

│ │ ├───.toolkit_linking_tool

│ │ ├───bin

│ │ │ ├───1033

│ │ │ └───compiler

│ │ │ ├───1033

│ │ │ └───intel64_ia32

│ │ ├───bin32

│ │ │ └───1033

│ │ ├───env

│ │ ├───etc

│ │ │ └───compiler

... other subdirectories removed for clarity

├───compiler_ide

│ └───2024.0

│ ├───.toolkit_linking_tool

│ └───share

│ └───ide_support

│ └───visual_studio

│ └───compiler

│ └───vs2022

│ ├───c++

│ ├───common_tools

│ ├───dpcpp

│ └───fortran

├───dal

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───env

│ ├───etc

│ │ └───dal

│ ├───include

│ │ ├───dal

│ │ │ ├───algorithms

... other subdirectories removed for clarity

├───debugger

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───env

│ ├───etc

│ │ └───debugger

│ │ └───sys_check

... other subdirectories removed for clarity

├───dev-utilities

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───env

│ ├───etc

│ ├───include

... other subdirectories removed for clarity

├───dnnl

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───env

... other subdirectories removed for clarity

├───dpcpp-ct

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───env

│ ├───etc

│ │ └───dpct

│ ├───include

... other subdirectories removed for clarity

├───dpl

│ └───2022.3

│ ├───.toolkit_linking_tool

│ ├───env

│ ├───etc

│ │ └───dpl

│ ├───include

... other subdirectories removed for clarity

├───hpckit

│ └───2024.0

│ └───.toolkit_linking_tool

├───inspector

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin32

│ │ ├───1033

│ │ └───runtime

│ ├───bin64

│ │ └───runtime

│ ├───config

... other subdirectories removed for clarity

├───ipp

│ └───2021.10

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───env

│ ├───etc

│ │ └───ipp

... other subdirectories removed for clarity

├───ippcp

│ └───2021.9

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───bin32

│ ├───env

│ ├───etc

│ │ └───ippcp

│ ├───include

... other subdirectories removed for clarity

├───itac

│ └───2022.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ │ └───platforms

│ ├───dll

│ │ └───common64

│ ├───env

│ ├───etc

... other subdirectories removed for clarity

├───licensing

│ └───2024.0

│ ├───.toolkit_linking_tool

│ └───licensing

│ └───2024.0

├───logs

├───mkl

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───env

│ ├───etc

│ │ └───mkl

│ ├───include

... other subdirectories removed for clarity

├───mpi

│ └───2021.11

│ ├───.toolkit_linking_tool

│ ├───bin

│ │ └───mpi

│ │ └───debug

│ ├───env

│ ├───etc

│ │ ├───conda

│ │ │ ├───activate.d

│ │ │ └───deactivate.d

│ │ └───mpi

│ ├───include

│ │ └───mpi

│ │ └───ilp64

│ ├───lib

... other subdirectories removed for clarity

├───tbb

│ └───2021.11

│ ├───.toolkit_linking_tool

│ ├───bin

│ │ ├───vc14_uwd

│ │ ├───vc14_uwp

│ │ └───vc_mt

│ ├───bin32

│ │ ├───vc14_uwd

│ │ ├───vc14_uwp

│ │ └───vc_mt

│ ├───env

│ ├───etc

... other subdirectories removed for clarity

├───tcm

│ └───1.0

│ ├───.toolkit_linking_tool

│ ├───bin

│ ├───bin32

│ └───share

│ └───doc

│ └───tcm

│ └───licensing

├───toolkit_linking_tool

│ ├───.envs

│ │ └───2024.0

│ │ ├───basekit

│ │ └───hpckit

│ └───2024.0

└───vtune

└───2024.0

├───.toolkit_linking_tool

├───backend

│ ├───bin64

│ └───proto

├───bin32

│ ├───gtpin

│ └───runtime

├───bin64

I am also attaching the installed copy of setvars.bat which doesn't seem to agree with the above directory structure. When setvars is run it doesn't seem to pick up on all the other vars.bat scripts it is supposed to execute.

SP_Van · ‎03-06-2024

Hi Steve - I posted a reply with a directory tree but it is not showing up in the thread. Can you confirm if you received it or should I post it again?

Barbara_P_Intel · ‎03-06-2024

I don't see the directory tree.

Maybe there's some info in Use the setvars and oneapi-vars Scripts with Windows that will help.

SP_Van · ‎03-06-2024

Thanks Barbara,

What is weird is that I now have two replies on this thread go AWOL. I read very carefully through the setvars and oneapi-vars usage docs for Windows and understand them, but the key problem is that the installed directory tree does not match what either setvars or oneapi-vars expect it to be. I will post this reply without a third attempt at the tree (which I will try to send in a following note).

SP_Van · ‎03-06-2024

Here's the tree again. Maybe there's a character limit being applied to these posts and so I will show only key subdirectories...

D:\Intel

└───oneAPI

├───advisor

│ └───2024.0

│ ├───.toolkit_linking_tool

│ ├───bin32

│ │ ├───1033

│ │ ├───gtpin

│ │ └───runtime

│ ├───bin64

│ │ ├───gtpin

│ │ ├───locales

│ │ ├───runtime

│ │ └───swiftshader

... other subdirectories removed for clarity

├───compiler

│ ├───2024.0

│ │ ├───.toolkit_linking_tool

│ │ ├───bin

│ │ │ ├───1033

│ │ │ └───compiler

│ │ │ ├───1033

│ │ │ └───intel64_ia32

│ │ ├───bin32

│ │ │ └───1033

│ │ ├───env

│ │ ├───etc

│ │ │ └───compiler

... other subdirectories removed for clarity

├───mpi

│ └───2021.11

│ ├───.toolkit_linking_tool

│ ├───bin

│ │ └───mpi

│ │ └───debug

│ ├───env

│ ├───etc

│ │ ├───conda

│ │ │ ├───activate.d

│ │ │ └───deactivate.d

│ │ └───mpi

│ ├───include

│ │ └───mpi

│ │ └───ilp64

│ ├───lib

... remaining subdirectories removed for clarity

Devorah_H_Intel · ‎03-06-2024

Did you try to open the preconfigured oneAPI shortcut - click Start >Intel oneAPI 2024> Intel oneAPI command prompt for Intel 64 for Visual Studio 2022?

Steve_Lionel · ‎03-06-2024

The problem isn't the directory tree, per se; Intel has changed it many times over the years. The big problem is that the system environment variables IFORT_COMPILER24 and PATH aren't updated to use the new folder structure. If you use the preinstalled shortcut, it should work, but that doesn't help if you run the program directly.

SP_Van · ‎03-06-2024

Yes - one of the first things I did. Copy and paste of what I get in the command window when I launch a session. The paths remain unset and therefore nothing works. I expect to see many more confirmations of the various vars.bat scripts running (e.g. for MPI) but they don't run.

:: initializing oneAPI environment...
Initializing Visual Studio command-line environment...
Visual Studio version 17.9.2 environment configured.
"C:\Program Files\Microsoft Visual Studio\2022\Professional\"
Visual Studio command-line environment initialized for: 'x64'
:: oneAPI environment initialized ::

D:\Intel\oneAPI>ifort
'ifort' is not recognized as an internal or external command,
operable program or batch file.

D:\Intel\oneAPI>

SP_Van · ‎03-06-2024

Hi Steve - if you can confirm which environment variables need to be set and to what values and which directories should be included in PATH (i.e. I can manually make those changes) perhaps that is a band aid for now.

What I have also noticed is that if I compile some test code with coarrays it fails to run even after I manually edit PATH to include the dlls it asks for. I suspect that VS 2022 is somehow missing some critical integration step that prevents coarray code from executing even though it compiles and links without issues.

Steve_Lionel · ‎03-07-2024

"Latest" is a softlink/alias that should be set up as part of the install. However, on one of my systems, "Latest" somehow ended up as a real folder and that prevented things from working. Here's what I suggest, as this fixed the problem for me.

Uninstall any Intel oneAPI product
Delete the Program Files (x86)\Intel\oneapi folder
Reboot
Reinstall the oneAPI product(s)

I gave above the environment variables that should be set (PATH should include the entries I showed), but the current installer probably won't get that right, so you'll have to fix it up. Even without doing this, using the Start menu shortcut for "Intel oneAPI command prompt" should give you an environment where the ifort (or ifx for x64) command is recognized.

Another issue for people who have had older versions is that the current installer doesn't remove from PATH the folders under Common Files that used to be for the run-time DLLs, and this can break programs. I think the Intel installer team really needs to get its act together - it's as if they just don't care (and don't test real-world situations.)

SP_Van · ‎03-07-2024

Hi Steve - I opened this thread for advice after I completed steps 1 to 4 in your latest post (and I actually did it twice)

And the shortcut to the "Intel oneAPI command prompt" just seems to run the buggy setvars.bat where the internal references to directories do not match with the installed directory structure.

I will try to manually add paths (as I have tried to in the past) but am disappointed that this has become such a monumental struggle.

Plus I haven't even started the new thread about why my test coarray code compiles and links without error in VS2022 but then doesn't run (it launches and ends but does nothing and the desired output doesn't materialise).

Steve_Lionel · ‎03-07-2024

What puzzles me is that you're the first I've seen with these complaints - it's not something I've seen across my three PCs with Intel Fortran installed. I use the setvars.bat all the time without issue.

Have you tried installing just Fortran and not the rest of the oneAPI stuff? See Solved: The Easy and Fast Way to Install JUST Fortran with Intel® oneAPI - Intel Community If you need selected other pieces, MKL for example, you can install thosse independently.

SP_Van · ‎03-07-2024

Hi Steve - wiped all of oneAPI, wiped manual changes to path, restarted the machine (which btw is running Server 2022). Installed only the 2024.0 Fortran compilers and I have the same problem with paths not being set correctly and ifort not being recognised when opening a oneAPI command prompt.

I think setvars.bat is broken. It doesn't seem to loop through the installed subdirectories. If I manually run each different vars.bat within the subfolders (e.g. compilers, mpi etc) then compiling and linking works from the command line but execution of code still needs manual addition of library paths.

And now for the coarray complaint (I used the code here to find the value of pi using random number generation...https://github.com/oneapi-src/oneAPI-samples/tree/master/DirectProgramming/Fortran/guided_Coarray)

When I compile and run the sequential version, the .exe runs without issue. However, while the coarray version successfully compiles it dies with an "Unknown option: -localonly" error.

d:\junk>ifx /exe:coarray /Qcoarray mcpi_coarray_final.F90
Intel(R) Fortran Compiler for applications running on Intel(R) 64, Version 2024.0.2 Build 20231213
Copyright (C) 1985-2023 Intel Corporation. All rights reserved.

-out:coarray.exe
-subsystem:console
mcpi_coarray_final.obj

....exe file generated at this point, but when I run it, no dice

d:\junk>coarray
Unknown option: -localonly

SP_Van · ‎03-08-2024

I think the problem is Windows Server 2022. The installer and/or the batch scripts have not been tested properly for this OS. I luckily found the offline installers for oneAPI 2023.2 on one of my older NUC boxes, wiped 2024.0 from the server machine, and installed 2023.2. Ran into the same problems with broken or missing path settings while the identical install on the NUC which is running Win 10 Pro works perfectly.

On the weird side, the coarray code which breaks on 2024.0, compiles and runs just fine with oneAPI 2023.2 on Win Server 2022 (see my earlier post about the -localonly error).

So it's all very very messy at the moment. I will stay with 2023.2 on the server machine (with manual path entries) since coarrays seems to be working. This has taken up a lot of my time and I thank Steve and Barbara for their help in trying to figure out the issue. Fingers crossed that 2024.1 fixes the apparent compatibility problems with Windows Server and coarrays starts to work again.

Steve_Lionel · ‎03-08-2024

The "not looping" happens if the softlinks for "latest" aren't set up properly. For example, this is what it looks like on my system:

See that little arrow? That means it's a shortcut/softlink. When I had issues, it was an actual folder and not a shortcut.

SP_Van · ‎03-08-2024

Steve - yes this has been a problem from the start. The install does not add the "latest" entries in a directory as shortcuts. They simply show up as folders.

Steve_Lionel · ‎03-08-2024

All I can say is that this works in Windows 11. Maybe what you can do is delete the folder and create a shortcut pointing to the 2024.0 folder in each of the component folders. It could be that your Windows Server is interfering somehow.