glib doesn't build with oneAPI on Ursa

[AlexanderHrabski-NOAA]

Description

#2068 updates the global workflow environment, which introduces a glib@2.88 dependency. During testing on Ursa, glib@2.88 failed to build with intel-oneapi-compilers@2025.3.1 via meson@1.11, producing the error:

ERROR: In override_options for atomic-c-23: None of values ['c23'] are supported by the C compiler. Possible values for option "c_std" are ['none', 'c89', 'c99', 'c11', 'c17', 'c18', 'c2x', 'gnu89', 'gnu99', 'gnu11', 'gnu17', 'gnu18', 'gnu2x']

Both @climbfuji and myself have built glib@2.88 with oneAPI compilers on our local systems, so this is an issue somehow related to configuration. See #2068 for additional context.

To Reproduce

Build the global workflow environment in #2068 on Ursa.

Expected behavior

glib should build.

System, compiler, code, ...

Ursa with the intel-oneapi-compilers@2025.3.1

Additional context

Add any other context about the problem here.

[AlexanderHrabski-NOAA]

Claude was able to figure this one out, and I was able to confirm the majority of it's explanation by reproducing the Ursa error locally. Here's what seems to be happening:

1. Meson uses a regex on the full output of icx --version to obtain the compiler version number. They search for exclusively 1 or 2 digit major version numbers first, and fall back to a 4 digit-capable regex only if the 1 or 2 digit regex comes back empty. The oneAPI version number that leads that string doesn't satisfy the filter because it's major version is 4 digits. However, there is a 2 digit major version in the string, and it shows up in the InstalledDir: line. On Ursa, gcc-11.4.1 appears:

[Alexander.Hrabski@ufe02 ~]$ icx --version
Intel(R) oneAPI DPC++/C++ Compiler 2025.3.1 (2025.3.1.20251023)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /apps/spack-2024-12/linux-rocky9-x86_64/gcc-11.4.1/intel-oneapi-compilers-2025.3.1-yqgrg5v3jonwexcjwd3xu3rzvwcp4ejk/compiler/2025.3/bin/compiler
Configuration file: /apps/spack-2024-12/linux-rocky9-x86_64/gcc-11.4.1/intel-oneapi-compilers-2025.3.1-yqgrg5v3jonwexcjwd3xu3rzvwcp4ejk/compiler/2025.3/bin/compiler/../icx.cfg

2. The reason there's a gcc-11.4.1 in the install path is explained by the first part of the path: These compilers were installed with spack, and 2024-12 predates predates the compiler-as-dependency layout change. Before then, every package had a compiler associated with it that would show up in the install path. This even includes installation of compiler binaries. I believe the gcc-11.4.1 is in this case completely spurious.
3. Meson recognizes the oneAPI compiler internally as intel-llvm. The version number now is set to 11.4.1, as we can see in the log:

[glib-meson-bug] alexhrabski@AHrabskiLaptop:~/spack$ grep "intel-llvm 11.4.1" meson-log.txt
C compiler for the host machine: /scratch4/NCEPDEV/marine/Alexander.Hrabski/spack-stack/envs/unified-env/install/none/none/compiler-wrapper-1.1.0-vids6zf/libexec/spack/oneapi/icx (intel-llvm 11.4.1 "Intel(R) oneAPI DPC++/C++ Compiler 2025.3.1 (2025.3.1.20251023)")

Meson correctly identifies that intel-llvm 11.4.1 doesn't support the c23 standard, and we obtain the error:

ERROR: In override_options for atomic-c-23: None of values ['c23'] are supported by the C compiler. Possible values for option "c_std" are ['none', 'c89', 'c99', 'c11', 'c17', 'c18', 'c2x', 'gnu89', 'gnu99', 'gnu11', 'gnu17', 'gnu18', 'gnu2x']

A true comedy of errors. Locally, I was able to reproduce this error by using an older spack to install the 2024.2.1 oneAPI compilers, and then use a recent spack to install glib with those compilers treated as external. Interestingly, on my machine, it's not a gcc version that Meson captures, but rather my Ubuntu WSL version:

[glib-meson-bug] alexhrabski@AHrabskiLaptop:~/spack$ grep "intel-llvm 22.04" meson-log.txt
C compiler for the host machine: /home/alexhrabski/spack/opt/spack/linux-alderlake/compiler-wrapper-1.1.0-7h32kb2knbvs67eclcf47j327i6ap3xw/libexec/spack/oneapi/icx (intel-llvm 22.04-skylake "Intel(R) oneAPI DPC++/C++ Compiler 2024.2.1 (2024.2.1.20240711)")
...

This actually successfully builds glib, because 22.04 is such a large version number that it passes the c23 check. If I modify the install path to instead have 11.4.1 in the name (and update the external package definition):

    intel-oneapi-compilers:
      externals:
      - spec: intel-oneapi-compilers@2024.2.1
        prefix: /home/alexhrabski/spack-old/opt/spack/linux-ubuntu11.4.1-skylake/gcc-12.3.0/intel-oneapi-compilers-2024.2.1-vooumvwifak6winja3ugyma6ppe2wy7t
        extra_attributes:
          compilers:
            c: /home/alexhrabski/spack-old/opt/spack/linux-ubuntu11.4.1-skylake/gcc-12.3.0/intel-oneapi-compilers-2024.2.1-vooumvwifak6winja3ugyma6ppe2wy7t/compiler/2024.2/bin/icx
            cxx: /home/alexhrabski/spack-old/opt/spack/linux-ubuntu11.4.1-skylake/gcc-12.3.0/intel-oneapi-compilers-2024.2.1-vooumvwifak6winja3ugyma6ppe2wy7t/compiler/2024.2/bin/icpx
      buildable: false

The error reproduces:

[glib-meson-bug] alexhrabski@AHrabskiLaptop:~/spack$ grep "intel-llvm 11.4.1" meson-log.txt
C compiler for the host machine: /home/alexhrabski/spack/opt/spack/linux-alderlake/compiler-wrapper-1.1.0-7h32kb2knbvs67eclcf47j327i6ap3xw/libexec/spack/oneapi/icx (intel-llvm 11.4.1-skylake "Intel(R) oneAPI DPC++/C++ Compiler 2024.2.1 (2024.2.1.20240711)")
...
[glib-meson-bug] alexhrabski@AHrabskiLaptop:~/spack$ grep "c23" meson-log.txt
...
ERROR: In override_options for atomic-c-23: None of values ['c23'] are supported by the C compiler. Possible values for option "c_std" are ['none', 'c89', 'c99', 'c11', 'c17', 'c18', 'c2x', 'gnu89', 'gnu99', 'gnu11', 'gnu17', 'gnu18', 'gnu2x']

I suspect our previous attempts with modern spack to reproduce the error locally failed because the compiler install paths didn't contain any 1 or 2 digit version numbers, so meson correctly fell back to the 4 digit regex:

alexhrabski@AHrabskiLaptop:~$ icx --version
Intel(R) oneAPI DPC++/C++ Compiler 2026.1.1 (2026.1.1.20260724)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /opt/intel/oneapi/compiler/2026.1/bin/compiler
Configuration file: /opt/intel/oneapi/compiler/2026.1/bin/compiler/../icx.cfg

I think it's definitely worth opening an issue with meson -- This was all done with meson@1.11.1, but it looks like this should still an issue in their master branch. I will confirm it's still an issue whenever I have time to work on this next. Unfortunately, glib only has a meson build system. As for a work around until this (hopefully) gets fixed upstream, it looks like there's a meson flag to turn the check off, but it isn't a spack variant. Adding a variant to turn the check off is the best work around I can think of, though I haven't confirmed it will work.

[climbfuji]

Oh wow. Thanks for figuring that out. I agree that this is worth a meson bug report and a spack variant to disable the meson check.

[rickgrubin-noaa]

Somewhat adjacent commentary, and a (perhaps rhetorical) question.

Comment: this is (for me, anyway) reminiscent of #1471, where meson refused to play nice with oneAPI compilers that were installed via spack (and for that issue, it was gcc-11.3.1 for a compiler install path).

Question: if adding a spack recipe variant to turn off the meson check doesn't "work," does an issue like this argue for installing oneAPI compilers with Intel's offline installer scripts instead of spack?

[climbfuji]

I know I am old style but until now - and reading the above probably also for a while longer - I was/am/will be in favor of installing compilers outside of spack and making them available as external packages. Same for MPI on HPCs (imo it's ok to install MPI with spack on dev boxes where we don't need to worry about the tuning and correct infiniband/... libraries and configuration options).