At least on Linux (both Debian- and RHEL-like) using Intel Oneapi repos, the new versions do not overwrite the previous but install “parallel”. Is there a simple way to use both the new and the old version alternatively? Unfortunately, the script to be sourced for proper environment, /opt/intel/oneapi/setvars.sh is placed in the top directory, so it always sets env for the latest version.
If it were possible, one could still use ifort from 2024.2 and the latest ifx (no intention to spark a discussion on wtf do you need ifort for?)
There’s actually a setvars.sh per compiler version, e.g., at /opt/intel/oneapi/compiler/2024.2/env/vars.sh —though it only sets the compiler, not the debugger.
(Not that I care that much, since gdb for Fortran leans towards “infuriating+frustrating”, hehehe).
That is correct. IFX only supports 64bit development. Keep your existing ifort installation, keep your OS at it’s current level, and do not allow Microsoft to push or install Visual Studio patches and updates as those have broken the integrations in the past and probably will do so again.
The Deprecation and Removal of ifort was announced in 2023 and was in the Release Notes documents ever since. In addition I wrote this article about the Deprecation and Removal, and another article in July 2024 announcing the last version of ifort.
I have updated the July article to capture the specific OS versions, and for Windows the Visual Studio versions that ifort 2021.13 supported at the time of it’s release. If you intend to keep using ifort, make sure to keep your development system at those OS and Visual Studio versions. Any future updates may break ifort.
These articles also mention that those with Priority Support will have access to download the 2024.2.1 oneAPI Fortran package containing ifort for one more year.
I’m experimenting with conda installation as shown here which is probably only option for Void Linux. It has installed flawlessly and on activation of the intel environment, I can run ifx on simple codes w/o any further action. When I tried, however, something more complicated, e.g. with OpenMP, the resulting executable had unresolved linkage to libimf.so and libiomp5.so. So I searched for *vars.sh files, finding those:
No setvars.sh or oneapi-vars.sh, mentioned elsewhere on Intel pages.
I sourced the ~/miniconda3/envs/intel/env/vars.sh and the program started to work but I am not sure if that is enough just for that particular code or for all. I guess this might deserve an explanation/clarification on Get Started on Linux page. Or, maybe it would be possible to preconfigure all needed variables (incl. LD_LIBRARY_PATH) in the conda env activation.
You are correct: Each component of oneAPI has a directory:
/env/vars.sh or sometimes setvars.sh. But in all cases, each component has an environment setup script in subdirectory “/env” Look for those to set environment for a specific component.
This is the reason I kept VS 2017 around to work with legacy Fortran, but Intel removed support for VS2017 in 2022.4 or something, kind of stealthy and now re-installing previous versions does not bring back the VS17 integrations. They are lost in time, as far as I am concerned.
I’ve confirmed this issue with the ifx_linux-64 conda packaging and your provided workaround, and I’ve also confirmed that the comparable C/C++ OpenMP variants compiled in a standalone dpcpp_linx-64 conda environment works out-of-the-box with no script sourcing needed. I’ll follow up on this internally.
Although, another workaround just struck me while writing that: installing dpcpp_linux-64 alongside ifx_linux-64 in the same conda environment, then reloading the conda environment, works and removes the need to run the env script.
One additional thing to note, if you’re using the ifx_linux-64 conda package to compile codes with Fortran Coarrays, you’ll also need to install the Intel MPI conda package as well. This is intentional behavior and is documented in Getting Started on Linux, but since this was not documented in the conda install instructions for ifx, figured I’d make it explicit here.