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.

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.