Compilers-as-nodes discussion

Since 5b3942a48935ee4aeef724b4a28c9666a75821c4, Spack implements compilers as nodes which are providers of languages ("provides('c')", "provides('fortran')", etc.). This will involve many changes to how we set compilers, and needs extensive testing as it is still a work in progress.

Let's use this issue to record issues encountered, best practices, tricks, etc.

See https://github.com/JCSDA/spack-stack/blob/b4094546b8956729d38bb3e901dbb3f3752f0809/configs/sites/tier1/acorn/packages_oneapi-2024.2.1.yaml for example of a working configuration with various bells and whistles (Cray wrapper with ifort, compiler flags, ...).

ursa

See configs/sites/tier1/ursa/packages_oneapi-2024.2.1.yaml for an example of a working configuration with oneAPI compilers + MPI.

When changing that configuration to build with MPI == hpc-x, installation fails when configuring nemsio@2.5.5:

==> nemsio: Executing phase: 'cmake'
[...]
-- The Fortran compiler identification is Intel 2021.1.0.20240703
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90
-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90 - broken
CMake Error at /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/gcc/12.4.0/cmake-3.31.8-ruodb2x/share/cmake-3.31/Modules/CMakeTestFortranCompiler.cmake:59 (message):
  The Fortran compiler

    "/apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90"

  is not able to compile a simple test program.
[...]
/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/none/none/compiler-wrapper-1.0-fbl56cg/libexec/spack/ld: line 401: SPACK_CXX_LINKER_ARG: ERROR: LINKER ARG WAS NOT SET, MAYBE THE PACKAGE DOES NOT DEPEND ON CXX?

When building with oneAPI MPI, it configures as

-- Check for working Fortran compiler: /apps/spack-2024-12/linux-rocky9-x86_64/oneapi-2024.2.1/intel-oneapi-mpi-2021.13.1-ss72gbndvat3oz22sa6lhmlbjkeabrn4/mpi/2021.13/bin/mpiifx - skipped
-- Found MPI_Fortran: /apps/spack-2024-12/linux-rocky9-x86_64/oneapi-2024.2.1/intel-oneapi-mpi-2021.13.1-ss72gbndvat3oz22sa6lhmlbjkeabrn4/mpi/2021.13/bin/mpiifx (found version "3.1")

and configure options are identical except for the value assigned to CMAKE_Fortran_COMPILER:STRING, and in both cases, the appropriate MPI Fortran compiler is identified.

The test env for oneAPI and HPC-X (spack-stack@1.9.2) successfully configures and builds nemsio:

-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-oneapi2024-ifort/bin/mpif90 - skipped
-- Found MPI_Fortran: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-oneapi2024-ifort/bin/mpif90 (found version "3.1")

Not sure what's missing for spack-stack@v2 / update to spack@v1

gaea-c6

See configs/sites/tier1/gaea-c6/packages_oneapi-2025.2.1.yaml for an example of a failing configuration on a simple spack env (for scotch@7.0.4)

spack.yaml

# spack-stack hash: 02890b1
# spack hash: 55cac73760
spack:
  concretizer:
    unify: when_possible
  view: false
  include:
  - site
  - common
  specs:
  - scotch@7.0.4

log.concretize

==> Concretized 1 spec:
 -   usin7oi  scotch@7.0.4~compression+esmumps~int64+metis+mpi~mpi_thread+noarch~shared~threads build_system=makefile arch=linux-sles15-zen4 %c,cxx,fortran=oneapi@2025.2.1
 -   exktf4z      ^bison@3.8.2~color build_system=autotools arch=linux-sles15-zen4 %c,cxx=gcc@12.3.0
 -   asbxlgv          ^diffutils@3.10 build_system=autotools arch=linux-sles15-zen4 %c=oneapi@2025.2.1
 -   qwey4ht              ^libiconv@1.18 build_system=autotools libs:=shared,static arch=linux-sles15-zen4 %c=oneapi@2025.2.1
[e]  tn3sv35          ^gcc@12.3.0~binutils+bootstrap~graphite~mold~nvptx~piclibs~profiled~strip build_system=autotools build_type=RelWithDebInfo languages:='c,c++' arch=linux-sles15-zen4
[e]  nwrttm4          ^gcc-runtime@12.3.0 build_system=generic arch=linux-sles15-zen4
 -   cobdxao          ^m4@1.4.20+sigsegv build_system=autotools arch=linux-sles15-zen4 %c,cxx=oneapi@2025.2.1
 -   wthr65z              ^libsigsegv@2.14 build_system=autotools arch=linux-sles15-zen4 %c=oneapi@2025.2.1
 -   jlib6fl      ^compiler-wrapper@1.0 build_system=generic arch=linux-sles15-zen4
[e]  q5xafc5      ^cray-mpich@8.1.32~cuda~rocm+wrappers build_system=generic arch=linux-sles15-zen4
[e]  vkqai7z      ^flex@2.6.4+lex~nls build_system=autotools patches:=f8b85a0 arch=linux-sles15-zen4
[e]  3pdohr5      ^glibc@2.38 build_system=autotools arch=linux-sles15-zen4
 -   5vlsqqd      ^gmake@4.4.1~guile build_system=generic arch=linux-sles15-zen4 %c=gcc@12.3.0
[e]  xqeyrjd      ^intel-oneapi-compilers@2025.2.1~amd+envmods~nvidia build_system=generic arch=linux-sles15-zen4
[e]  jpmgrzr      ^intel-oneapi-runtime@2025.2.1 build_system=generic arch=linux-sles15-zen4

The installation succeeds in building gmake@4.4.1 with gcc@12.3.0, and then fails to build libiconv@1.18 with oneapi@2025.2.1 with this error:

==> Installing gmake-4.4.1-5vlsqqdrif4iuxsdxsndjftz3xcagdgg [9/15]
==> No binary for libiconv-1.18-qwey4htei6mjf3rnftneb7l665rwah5y found: installing from source
==> Warning: /gpfs/f6/scratch/Richard.Grubin/bil-fire8/v2.0/spack-stack/repos/builtin/repos/spack_repo/builtin/packages/compiler_wrapper/package.py:174: when setting environment variable SPACK_CC=None: value is of type `NoneType`, but `str` was expected. This is deprecated and will be an error in Spack v1.0
[...]
checking for gcc... /gpfs/f6/scratch/Richard.Grubin/bil-fire8/v2.0/spack-stack/envs/scotch-7.0.4-oneapi-2025.2.1/install/none/none/compiler-wrapper-1.0-jlib6fl/libexec/spack/oneapi/icx
checking whether the C compiler works... no
configure: error: in '/gpfs/f6/bil-fire8/scratch/Richard.Grubin/v2.0/spack-stack/cache/build_stage/spack-stage-libiconv-1.18-qwey4htei6mjf3rnftneb7l665rwah5y/spack-src':
configure: error: C compiler cannot create executables

and the config.log file for libiconv reports

configure:3401: checking for gcc
configure:3433: result: /gpfs/f6/scratch/Richard.Grubin/bil-fire8/v2.0/spack-stack/envs/ue-oneapi-2025.2.1/install/none/none/compiler-wrapper-1.0-jlib6fl/libexec/spack/oneapi/icx
configure:3786: checking for C compiler version
configure:3795: /gpfs/f6/scratch/Richard.Grubin/bil-fire8/v2.0/spack-stack/envs/ue-oneapi-2025.2.1/install/none/none/compiler-wrapper-1.0-jlib6fl/libexec/spack/oneapi/icx --version >&5
None

so the configuration specification(s) for intel-oneapi-compilers is somehow wrong.

@AlexanderRichert-NOAA

ursa

See configs/sites/tier1/ursa/packages_oneapi-2024.2.1.yaml for an example of a working configuration with oneAPI compilers + MPI.

When changing that configuration to build with MPI == hpc-x, installation fails when configuring nemsio@2.5.5:

==> nemsio: Executing phase: 'cmake'
[...]
-- The Fortran compiler identification is Intel 2021.1.0.20240703
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90
-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90 - broken
CMake Error at /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/gcc/12.4.0/cmake-3.31.8-ruodb2x/share/cmake-3.31/Modules/CMakeTestFortranCompiler.cmake:59 (message):
  The Fortran compiler

    "/apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90"

  is not able to compile a simple test program.
[...]
/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/none/none/compiler-wrapper-1.0-fbl56cg/libexec/spack/ld: line 401: SPACK_CXX_LINKER_ARG: ERROR: LINKER ARG WAS NOT SET, MAYBE THE PACKAGE DOES NOT DEPEND ON CXX?

When building with oneAPI MPI, it configures as

-- Check for working Fortran compiler: /apps/spack-2024-12/linux-rocky9-x86_64/oneapi-2024.2.1/intel-oneapi-mpi-2021.13.1-ss72gbndvat3oz22sa6lhmlbjkeabrn4/mpi/2021.13/bin/mpiifx - skipped
-- Found MPI_Fortran: /apps/spack-2024-12/linux-rocky9-x86_64/oneapi-2024.2.1/intel-oneapi-mpi-2021.13.1-ss72gbndvat3oz22sa6lhmlbjkeabrn4/mpi/2021.13/bin/mpiifx (found version "3.1")

and configure options are identical except for the value assigned to CMAKE_Fortran_COMPILER:STRING, and in both cases, the appropriate MPI Fortran compiler is identified.

The test env for oneAPI and HPC-X (spack-stack@1.9.2) successfully configures and builds nemsio:

-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-oneapi2024-ifort/bin/mpif90 - skipped
-- Found MPI_Fortran: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-oneapi2024-ifort/bin/mpif90 (found version "3.1")

Not sure what's missing for spack-stack@v2 / update to spack@v1

This one's easy, just add the missing dependency on C++ in nemsio (although I am surprised that nemsio depends on C++ - @AlexanderRichert-NOAA )

ursa

> > /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/none/none/compiler-wrapper-1.0-fbl56cg/libexec/spack/ld: line 401: SPACK_CXX_LINKER_ARG: ERROR: LINKER ARG WAS NOT SET, MAYBE THE PACKAGE DOES NOT DEPEND ON CXX?

Not sure what's missing for spack-stack@v2 / update to spack@v1

This one's easy, just add the missing dependency on C++ in nemsio (although I am surprised that nemsio depends on C++ - @AlexanderRichert-NOAA )

Not clear to me what you mean (or, it's not easy for me!) -- if nemsio builds with oneAPI MPI then it seems the dependency on C++ is satisfied, but not so for HPC-X MPI, so not sure what the change is -- to nemsio cmake / configure bits?

nemsio doesn't depend on C++, unless it does so through a dependency... It would help to see the output from CMake's test invocation of mpif90 if you're able to conjure that up.

orion

See configs/sites/tier1/orion/packages_oneapi-2024.2.1.yaml for an example of a nearly successful build -- fails to build py-scipy, in the step where meson configures the package:

For this concretization

^py-scipy@1.16.0 build_system=python_pip arch=linux-rocky9-skylake_avx512 %c,cxx,fortran=oneapi@2024.2.1

the failure is

The Meson build system
 Version: 1.7.0
 Source dir: /work2/noaa/epic/rgrubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-py-scipy-1.16.0-oydhvdysqrccubzeoxc2dg4wvll5fuct/spack-src
 Build dir: /work2/noaa/epic/rgrubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-py-scipy-1.16.0-oydhvdysqrccubzeoxc2dg4wvll5fuct/spack-src/build
 Build type: native build
 Project name: scipy
 Project version: 1.16.0

 ../meson.build:1:0: ERROR: None of values ['c17'] are supported by the C compiler. Possible values for option "C_std" are ['none', 'c89', 'c99', 'c11', 'gnu89', 'gnu99', 'gnu11']

On orion (and hercules) in particular, when building with spack-stack@1.9.x and spack@0.23.x, this was solved by setting

py-scipy:
  require:
  - '%gcc'

On other hosts (e.g. ursa), py-scipy builds with the same compiler -- oneapi@2-24.2.1 -- right down to the release date -- both orion and ursa report:

Intel(R) oneAPI DPC++/C++ Compiler 2024.2.1 (2024.2.1.20240711)

Intel(R) oneAPI DPC++/C++ Compiler 2024.2.1 (2024.2.1.20240711)

ifort (IFORT) 2021.13.1 20240703

In other words, on another host with identical compilers, using gcc was not required.

Attempted solutions:

spec gcc for py-scipy
- loads of duplicate packages when concretizing (so likely a misconfigured packages_oneapi-2024.2.1.yaml file)
specify -c11 or -c17 specifically for py-scipy
- same failure

On orion, meson-log.txt file reports the failure as:

The Meson build system
Version: 1.7.0
Source dir: /work2/noaa/epic/rgrubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-py-scipy-1.16.0-2p6ehzlqukxpaxnsyajfpn4vg4xbijdp/spack-src
Build dir: /work2/noaa/epic/rgrubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-py-scipy-1.16.0-2p6ehzlqukxpaxnsyajfpn4vg4xbijdp/spack-src/build
Build type: native build
Running command: /work2/noaa/epic/rgrubin/git/v2.0/envs/orion/ue-oneapi-2024.2.1/install/none/none/python-venv-1.0-cjidwed/bin/python3 /work2/noaa/epic/rgrubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-py-scipy-1.16.0-2p6ehzlqukxpaxnsyajfpn4vg4xbijdp/spack-src/tools/gitversion.py
--- stdout ---
1.16.0

--- stderr ---

Project name: scipy
Project version: 1.16.0
-----------
Detecting compiler via: `/work2/noaa/epic/rgrubin/git/v2.0/envs/orion/ue-oneapi-2024.2.1/install/none/none/compiler-wrapper-1.0-wrke2w4/libexec/spack/oneapi/icx --version` -> 0
stdout:
Intel(R) oneAPI DPC++/C++ Compiler 2024.2.1 (2024.2.1.20240711)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /apps/spack-managed-x86_64_v3-v1.0/gcc-11.3.1/intel-oneapi-compilers-2024.2.1-podbez65l57ms4uba527kg7pomxk5y3m/compiler/2024.2/bin/compiler
Configuration file: /apps/spack-managed-x86_64_v3-v1.0/gcc-11.3.1/intel-oneapi-compilers-2024.2.1-podbez65l57ms4uba527kg7pomxk5y3m/compiler/2024.2/bin/compiler/../icx.cfg

-----

Detecting linker via: `/work2/noaa/epic/rgrubin/git/v2.0/envs/orion/ue-oneapi-2024.2.1/install/none/none/compiler-wrapper-1.0-wrke2w4/libexec/spack/oneapi/icx -Wl,--version` -> 0
stdout:
GNU ld version 2.35.2-24.el9
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
-----------

../meson.build:1:0: ERROR: None of values ['c17'] are supported by the C compiler. Possible values for option "C_std" are ['none', 'c89', 'c99', 'c11', 'gnu89', 'gnu99', 'gnu11']

whereas a successful build on ursa reports

The Meson build system
 Version: 1.7.0
 Source dir: /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-py-scipy-1.16.0-uiensyprvcngpeggyoh22wp5amnqmtlc/spack-src
 Build dir: /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-py-scipy-1.16.0-uiensyprvcngpeggyoh22wp5amnqmtlc/spack-src/build
 Build type: native build
 Project name: scipy
 Project version: 1.16.0
 C compiler for the host machine: /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1/install/none/none/compiler-wrapper-1.0-fbl56cg/libexec/spack/oneapi/icx (intel-llvm 11.4.1 "Intel(R) oneAPI DPC++/C++ Compiler 2024.2.1 (2024.2.1.20240711)")
 C linker for the host machine: /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1/install/none/none/compiler-wrapper-1.0-fbl56cg/libexec/spack/oneapi/icx ld.bfd 2.35.2-43

Not at all clear to me why the same compilers / specs succeed on one host but not another, and this has persisted across versions of spack.

nemsio doesn't depend on C++, unless it does so through a dependency... It would help to see the output from CMake's test invocation of mpif90 if you're able to conjure that up.

Full build log:
==> nemsio: Executing phase: 'cmake'
==> [2025-10-24-00:51:52.467208] '/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/gcc/12.4.0/cmake-3.31.8-ruodb2x/bin/cmake' '-G' 'Unix Makefiles' '-DCMAKE_INSTALL_PREFIX:STRING=/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/intel-oneapi-compilers/2024.2.1/nemsio-2.5.5-y7qvos5' '-DCMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOL=ON' '-DCMAKE_INSTALL_RPATH:STRING=/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/intel-oneapi-compilers/2024.2.1/nemsio-2.5.5-y7qvos5/lib;/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/intel-oneapi-compilers/2024.2.1/nemsio-2.5.5-y7qvos5/lib64' '-DCMAKE_PREFIX_PATH:STRING=/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/gcc/12.4.0/cmake-3.31.8-ruodb2x;/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/none/none/compiler-wrapper-1.0-fbl56cg;/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/gcc/12.4.0/gmake-4.4.1-sjbritz;/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/intel-oneapi-compilers/2024.2.1/w3emc-2.10.0-qb63f6x;/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/intel-oneapi-compilers/2024.2.1/bacio-2.6.0-uvpzx4o;/apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort;/apps/spack-2024-12/linux-rocky9-x86_64/gcc-11.4.1/intel-oneapi-compilers-2024.2.1-oqhstbmawnrsdw472p4pjsopj547o6xs;/apps/spack-2024-12/linux-rocky9-x86_64/gcc-11.4.1/intel-oneapi-compilers-2024.2.1-oqhstbmawnrsdw472p4pjsopj547o6xs' '-DCMAKE_BUILD_TYPE:STRING=Release' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' '-DCMAKE_INTERPROCEDURAL_OPTIMIZATION:BOOL=OFF' '-DCMAKE_POLICY_DEFAULT_CMP0090:STRING=NEW' '-DCMAKE_FIND_USE_PACKAGE_REGISTRY:BOOL=OFF' '-DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=ON' '-DENABLE_MPI:BOOL=ON' '-DCMAKE_Fortran_COMPILER:STRING=/apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90' '/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/spack-stack/cache/build_stage/spack-stage-nemsio-2.5.5-y7qvos5mqcvo3nokmpoy3sbvmwwjsw66/spack-src'
-- The Fortran compiler identification is Intel 2021.1.0.20240703
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - failed
-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90
-- Check for working Fortran compiler: /apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90 - broken
CMake Error at /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/gcc/12.4.0/cmake-3.31.8-ruodb2x/share/cmake-3.31/Modules/CMakeTestFortranCompiler.cmake:59 (message):
  The Fortran compiler
mpif90 - broken
CMake Error at /scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/gcc/12.4.0/cmake-3.31.8-ruodb2x/share/cmake-3.31/Modules/CMakeTestFortranCompiler.cmake:59 (message):
  The Fortran compiler

    "/apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90"

  is not able to compile a simple test program.

(sorry about the long line of text)

Depends on

    depends_on("bacio")
    [...]
    # nemsio 2.5.3 and later depend on w3emc-2.9.0 or later.
    depends_on("w3emc@2.9.0:", when="@2.5.3:")

and the output from spack install shows that:

/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/intel-oneapi-compilers/2024.2.1/w3emc-2.10.0-qb63f6x

/scratch3/NCEPDEV/nems/Richard.Grubin/git/v2.0/envs/ue-oneapi-2024.2.1-hpcx/install/intel-oneapi-compilers/2024.2.1/bacio-2.6.0-uvpzx4o

Edited to add: a simple env that doesn't set the +mpi variant builds; when +mpi is introduced, the build fails; simple spack.yaml to demonstrate:

spack:
  concretizer:
    unify: when_possible

  view: false
  include:
  - site
  - common

  specs:
  - nemsio ~ipo +mpi

@AlexanderRichert-NOAA

I am not sure if your nemsio issue is related to this, but I also ran into the same error message.

I started looking inside the spack compiler/linker wrapper ~/work/spack-stack/update-to-spack-v1/spst-upd-to-spack-v1/envs/adp-gcc-13.3.1/install/none/none/compiler-wrapper-1.0-tf56dks/libexec/spack/ld and came across this:

    ld|ld.gold|ld.lld)
        mode=ld
        if [ -z "$SPACK_CC_RPATH_ARG" ]; then
            comp="CXX"
        fi
        ;;

That is, in linker mode spack is looking for SPACK_CC_RPATH_ARG and if that doesn't exist in the environment (e.g. if the package doesn't depend on c), then it thinks that C++ is used. In my opinion, this is an oversight. There must be a way to compile and link with Fortran only. @AlexanderRichert-NOAA what do you think?

I am not sure if your nemsio issue is related to this, but I also ran into the same error message.

I started looking inside the spack compiler/linker wrapper ~/work/spack-stack/update-to-spack-v1/spst-upd-to-spack-v1/envs/adp-gcc-13.3.1/install/none/none/compiler-wrapper-1.0-tf56dks/libexec/spack/ld and came across this:
    ld|ld.gold|ld.lld)
        mode=ld
        if [ -z "$SPACK_CC_RPATH_ARG" ]; then
            comp="CXX"
        fi
        ;;
That is, in linker mode spack is looking for SPACK_CC_RPATH_ARG and if that doesn't exist in the environment (e.g. if the package doesn't depend on c), then it thinks that C++ is used. In my opinion, this is an oversight. There must be a way to compile and link with Fortran only. @AlexanderRichert-NOAA what do you think?

Data point:

I updated repos/spack_repo/builtin/packages/compiler_wrapper/cc.sh as per this PR: Update compiler_wrapper/cc.sh: choose compiler in mode 'ld' #2165

and see the same failure when trying to build nemsio ~ipo +mpi on ursa

  The Fortran compiler
    "/apps/hpcx-v2.18.1-gcc-mlnx_ofed-redhat9-cuda12-x86_64/ompi-mt-oneapi2024-ifort/bin/mpif90"

  is not able to compile a simple test program.

  It fails with the following output:
[...]
  SPACK_CXX_LINKER_ARG: ERROR: LINKER ARG WAS NOT SET, MAYBE THE PACKAGE DOES NOT DEPEND ON CXX?

Also tried this on gaea-c6 / scotch@7.0.4 -- same failure as described in that comment, however I still think this error is a site configuration error.

Maybe it's not mode "ld" in your case? Read through the compiler wrapper and try to find places where it falls back to CXX.

Maybe it's not mode "ld" in your case? Read through the compiler wrapper and try to find places where it falls back to CXX.

Perhaps not for mode ld, but rather for mode c++ etc. (in the same case statement), which still begs the question as to why it's an issue in the first place as nemsio doesn't depend on C++.

I suppose it warrants diving into what cmake is trying to do in this case.

Navigation Menu

Repository navigation

Compilers-as-nodes discussion #1604

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Compilers-as-nodes discussion #1604

Description

Activity

AlexanderRichert-NOAA commented on Oct 9, 2025

rickgrubin-tomorrow commented on Oct 24, 2025

rickgrubin-tomorrow commented on Oct 24, 2025

climbfuji commented on Oct 24, 2025

rickgrubin-noaa commented on Oct 24, 2025

AlexanderRichert-NOAA commented on Oct 24, 2025

rickgrubin-noaa commented on Oct 24, 2025

rickgrubin-noaa commented on Oct 24, 2025

climbfuji commented on Oct 27, 2025

rickgrubin-noaa commented on Oct 30, 2025

climbfuji commented on Oct 30, 2025

rickgrubin-noaa commented on Oct 30, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions