Intel Oneapi toolchain run into `fortran-rt` provider conflict with `gcc-runtime`

When building packages with gcc, Spack requires them to depend on a gcc-runtime package. Conversely, packages built with the oneapi compiler, depend on a oneapi-runtime package. The problem arises from both of these packages wanting to be the sole provider, specifically, of fortran-rt. With "unified concretisation" this is unable to resolve.

One potential solution is abandon the unified concretisation in favour of when-possible. This does incur greater risk of packages being installed without the specific dependency chain we're looking for

Another potential solution was suggested when the issue was brought up in Slack with a different user running into it:

My situation: building an environment using intel-oneapi-compilers wherever possible (and thus depend on intel-oneapi-runtime); exceptions are bison, gcc-runtime, and libbsd, which are built with GNU compilers. These packages are constrained in packages.yaml with require: '%gcc'

As in your case, it appears that a dependency on gcc-runtime leads to both runtime packages wanting to provide fortran-rt , as seen by the output from spack diff /hash1 /hash2 For my situation, concretization is unify: when_possible and spack.yaml specifies prefer: ['%oneapi'] for all packages, and am also using an internal fork of spack; I'll have to check as to how up to date with spack/develop it is. It seems that adding intel-oneapi-runtime as an external (as with the compiler and MPI specs) to packages.yaml, e.g.

  intel-oneapi-runtime:
    externals:
    - spec: intel-oneapi-runtime@2024.2.1%oneapi@2024.2.1
      prefix: /apps/oneapi/compiler/2024.2 
      modules:
      - compiler-rt/2024.2.1

resolves duplicates