Ursa spack-stack/2.0.0 bacio/2.6.0 INC and LIB variables point at non-existent paths

[RussTreadon-NOAA]

Description

While module show bacio/2.6.0 returns

setenv("BACIO_LIB4", "/contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/bacio-2.6.0-2ecrwd4/lib/libbacio_4.a")
setenv("BACIO_LIB8", "/contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/bacio-2.6.0-2ecrwd4/lib/libbacio_8.a")

directory /contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/bacio-2.6.0-2ecrwd4/lib does not exist.

Instead we have /contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/bacio-2.6.0-2ecrwd4/lib64 which contains

drwxr-sr-x 3 role.epic epic  2048 Jan  6 21:29 cmake
-rw-r--r-- 1 role.epic epic 27870 Jan  6 21:29 libbacio.a

The same comment applies to BACIO_INC4 and BACIO_INC8. Neither of directories to which bacio/2.6.0 points exist.

To Reproduce

Execute the following on Ursa

module purge
module use /contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/modules/Core
module load stack-intel-oneapi-compilers/2025.2.1
module load bacio/2.6.0
module show bacio/2.6.0

The paths for BACIO_INC4, BACIO_INC8, BACIO_LIB4, and BACIO_LIB8 do not exist.

Expected behavior

The paths for BACIO_INC4, BACIO_INC8, BACIO_LIB4, and BACIO_LIB8 should exist and be populated with the appropriate files.

System, compiler, code, ...

stack-intel-oneapi-compilers/2025.2.1

Additional context

Encountered this issue while attempting to build NOAA-EMC/GSI on Ursa using spack-stack/2.0.0.

GSI is built with bacio_4. The build failed because bacio_4 could not be found.

[climbfuji]

I think that the new version of BACIO bundles everything in one library. It's probably just a matter of pointing the legacy env variables to libbacio.a. You could try that manually after loading the spack-stack environments. If it works, then we can fix that in spack-stack develop and release in 2.1.0.

@AlexanderRichert-NOAA FYI

[RussTreadon-NOAA]

Thank you @climbfuji . I replaced bacio_4 with bacio. The GSI build got a bit further but died with

CMake Error at src/gsi/CMakeLists.txt:158 (target_link_libraries):
  Target "gsi_fortran_obj" links to:

    crtm::crtm

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

We currently build GSI with crtm/2.4.0.1 when using spack-stack/1.9.2. crtm/2.4.0.1 needs stack-oneapi/2024.2.1 but when we move to spack-stack/2.0.0 we use stack-intel-oneapi-compilers/2025.2.1.

I tried crtm/3.1.2 and got the above build error.

[climbfuji]

Thank you @climbfuji . I replaced bacio_4 with bacio. The GSI build got a bit further but died with

CMake Error at src/gsi/CMakeLists.txt:158 (target_link_libraries):
  Target "gsi_fortran_obj" links to:

    crtm::crtm

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

We currently build GSI with crtm/2.4.0.1 when using spack-stack/1.9.2. crtm/2.4.0.1 needs stack-oneapi/2024.2.1 but when we move to spack-stack/2.0.0 we use stack-intel-oneapi-compilers/2025.2.1.

I tried crtm/3.1.2 and got the above build error.

@DavidHuber-NOAA I suppose you've seen this before?

[DavidHuber-NOAA]

@climbfuji No, this is the first time I have seen this, though I do see the issue. The CRTM module files (/contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/modules/intel-oneapi-mpi/2021.13/intel-oneapi-compilers/2025.2.1/crtm/v2.4.1-jedi.2.lua and 3.1.2.lua) both have the wrong CRTM_LIB variable defined. For 3.1.2, we have

setenv("CRTM_LIB", "/contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/crtm-3.1.2-zhiwr3y/lib/libcrtm.a")

But ls /contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/crtm-3.1.2-zhiwr3y/lib shows

libcrtm.so

For v2.4.1-jedi, both the path to the library directory and the library name are incorrect

setenv("CRTM_LIB", "/contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/crtm-v2.4.1-jedi.2-qr6hazm/lib/libcrtm.a")

> ls /contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/crtm-v2.4.1-jedi.2-qr6hazm/lib
ls: cannot access '/contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/crtm-v2.4.1-jedi.2-qr6hazm/lib': No such file or directory
> ls /contrib/spack-stack/spack-stack-2.0.0/envs/ue-oneapi-2025.2.1/install/intel-oneapi-compilers/2025.2.1/crtm-v2.4.1-jedi.2-qr6hazm/lib64
cmake/  libcrtm.so  libcrtm_static.a

This could probably be hacked in the GSI module file by redefining the CRTM_LIB variable after loading the crtm module to point to the correct path.

[climbfuji]

I see now. crtm@v2.4..1-jedi.2 is the JEDI version of CRTM that was never intended for EMC use. For crtm versions 2, there were always separate versions for EMC applications and JEDI. From crtm@3 on, there is only one version for all applications.

crtm@2.4.0_emc (I believe it was called) is no longer included in spack-stack@2, since the expectation was (not from me, I don't remember where/how this came up) that EMC will be moving to crtm@3 with spack-stack@2

[climbfuji]

It looks like that you could "fix" the wrong environment variables manually/in the GSI scripts for testing (both BACIO and CRTM - use 3.1.2) and if that works we can fix the modules in spack-stack for release 2.1.0?