Skip to content

Post‐release updates for spack‐stack‐1.8.0

Jump to bottom
Stephen Herbener edited this page May 5, 2025 · 5 revisions

Introduction

This page provides updates for the spack-stack-1.8.0 release that are not included in the release documentation (https://spack-stack.readthedocs.io/en/1.8.0). These updates arise from the fact that additional packages get installed over the lifetime of a release (usually one year, sometimes longer), HPC systems are updated, issues are identified etc.

Environment updates

Updates for pre-configured sites

Package updates

Known issues

  1. MSU Orion

    The Intel based unified environment has an issue with the LD_LIBRARY_PATH setting that causes the system tar (/usr/bin/tar) to fail with the following error message.

    (venv-intel) orion-login-4[131] herbener$ tar xzfv fix_REL-3.1.1.2.tgz 
tar: Relink `/apps/spack-managed/gcc-11.3.1/intel-oneapi-compilers-2023.1.0- 
sb753366rvywq75zeg4ml5k5c72xgj72/compiler/2023.1.0/linux/compiler/lib/intel64_lin/libimf.so' with `/usr/lib64/libm.so.6' 
for IFUNC symbol `sincosf'
Segmentation fault (core dumped)

    This call to tar is what the CRTM CMake configuration attempts to do (and fails) when running ecbuild on jedi-bundle. The issue is that the LD_LIBRARY_PATH places the spack-stack built libcrypt shared library in front of the system libcrypt shared library. The spack-stack libcrypt library has different dependencies compared to the systme libcrypt libary and the subsequent loading of depndencies gets fouled up. Tthe bottom line is that LD_LIBRARY_PATH needs to be modified to get tar to run properly, and getting CMake to do this during the ecbuild flow turns out to be difficult to do.

    There exists a manual workaround for this tar issue, which is to manually run tar in between two successive runs of ecbuild. Here is an example:

    cd <build-directory>

# this run will crash with the above error
ecbuild -DMPIEXEC_EXECUTABLE=$(which srun) -DMPIEXEC_NUMPROC_FLAG="-n" <source-directory>

# run the tar command manually
cd <build-directory>/test_data/3.1.1
LD_LIBRARY_PATH="" tar xzvf fix_REL-3.1.1.2.tgz

# re-run ecbuild, this run will complete
cd <build-directory>
ecbuild -DMPIEXEC_EXECUTABLE=$(which srun) -DMPIEXEC_NUMPROC_FLAG="-n" <source-directory>

# continue with jedi-bundle build process
make -j8
...

  2. spack-stack-1.8.0 (and earlier installations) As of 4/28/25 (when this PR was merged: https://github.com/JCSDA-internal/ioda/pull/1300) there is an issue with building the current develop branches of jedi-bundle where the CMake configuration gets confused about the bufr-query version.

    • spack-stack-1.8.0 contains version 0.0.2 of the bufr-query package
    • Version 0.0.2 of the bufr-query library unfortunately specifies version 2.8.0 in its cmake project command
    • With the merging of IODA PR1300, the find_package command for bufr-query added 0.0.4 as its required version
      • Prior to IODA PR1300, the find_package command for bufr-query did not specify a version

    The bufr-query version 0.0.4 library is indeed required for the develop branch in IODA to compile correctly, but unfortunately in spack-stack-1.8.0 the cmake configuration thinks the available bufr-query version is 2.8.0 (instead of 0.0.2), the bufr-query package is accepted, and the subsequent build fails because the bufr-query library is not compatible. The effort to go around and patch all of the spack-stack-1.8.0 installations is quite large so it was decided to instead workaround this issue (when you don't require the BUFR backend) by simply doing a

    module unload bufr-query

    command before building jedi-bundle. (NOAA-EMC has a way to deal with this in their environments to enable the BUFR backend.)

    This issue has been repaired for spack-stack-1.9.0 and newer versions moving forward.

Clone this wiki locally