Known Issues

This page describes known issues for the spack-stack develop code. Other known issues for specific releases of spack-stack are described in the end user docs for the respective releases.

General issues

1. python on Cray is non-functional: Could not find platform dependent libraries <exec_prefix>

   This problem and the solution to unset the environment variable CONFIG_SITE before building spack-stack environments is described in https://github.com/spack/spack/issues/40110 and https://github.com/spack/spack/issues/42132.

2. Build errors for mapl@2.35.2 with mpich@4.1.1

   This problem is described in https://github.com/JCSDA/spack-stack/issues/608.

3. Issues starting/finding ecflow_server due to a mismatch of hostnames

   On some systems, ecflow_server gets confused by multiple hostnames, e.g. localhost and MYORG-L-12345. The ecflow_start.sh script reports the hostname it wants to use. This name (or both) must be in /etc/hosts in the correct address line, often the loopback address (127.0.0.1).

4. Installing/using graphical applications after switching user using sudo su

   When using a role account to install spack-stack, it is sometimes necessary to run graphical applications such as the qt online installer. The following website describes in detail how this can be done: https://www.thegeekdiary.com/how-to-set-x11-forwarding-export-remote-display-for-users-who-switch-accounts-using-sudo/

5. Runtime segmentation faults for applications with Intel Classic or Intel LLVM compilers: Relink `/opt/intel/oneapi/compiler/2024.0/lib/libirc.so' with `/lib/x86_64-linux-gnu/libc.so.6' for IFUNC symbol `memmove' - Segmentation fault (core dumped).

   This problem is caused by a bad library in the Intel oneAPI installation. The solution is to fix the library using patchelf, which requires write access to the oneAPI installation: First, verify that ldd /opt/intel/oneapi/compiler/2024.0/lib/libirc.so says it is statically linked (it isn't). Then, run: patchelf --add-needed libc.so.6 /opt/intel/oneapi/compiler/2024.0/lib/libirc.so and your application should run rightaway (no need to recompile). A similar approach can be used for libimf.so by adding the missing symbols from libm.so.6.

   Fixing Intel oneAPI libraries isn't always an option. Another solution is to link against the correct, new shared version of these libraries (libintlc.so etc). This can be done by adding the linker option shared-intel for spack-built packages to the Spack package recipe and/or to any downstream build system. See also here.

Site-specific issues

NASA Discover

1. Timeout when fetching software during spack installs.

   Discover's connection to the outside world can be very slow and spack sometimes aborts with fetch timeouts. Try again until it works, sometimes you just have to wait for a bit.

2. configure: error: cannot guess build type; you must specify one when building freetype or other packages that use configure scripts

   This can happen if a spack install is started in a screen session, because Discover puts the temporary data in directories like /gpfsm/dnb33/tdirs/login/discover13.29716.dheinzel, which get wiped out after some time. Without screen, this problem doesn't occur.

3. Insufficient diskspace when building py-pytorch

   This is because py-pytorch uses directory ~/.ccache during the build, and the user's home directories have small quotas set. This problem can be avoided by creating a symbolic link from the home directory to a different place with sufficient quota: rm -fr ~/.ccache && ln -sf /path/to/dot_ccache_pytorch/ ~/.ccache. It's probably a good idea to revert this hack after a successful installation.

NOAA Parallel Works

1. With the default module path, spack will detect the system as Cray, therefore one needs to remove it when building or using spack environments.

2. libxml2 won't untar during the spack install step, because of an issue with the filesystem. This can be avoided by making libxml2 an external package.

UW (Univ. of Wisconsin) S4

1. Compiler errors when using too many threads for parallel builds.

   Using more than two threads when running make (e.g. make -j4) can lead to compiler errors like the following. To avoid this, reduce the number of threads in the site config's config.yaml file.

   [94%] Linking CXX executable test_ufo_parameters
   icpc: error #10106: Fatal error in /home/opt/intel/oneapi/2022.1/compiler/2022.0.1/linux/bin/intel64/../../bin/intel64/mcpcom, terminated by kill signal
   

macOS

1. Installation of gdal fails with error xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance.

   If this happens, install the full Xcode application in addition to the Apple command line utilities, and switch xcode-select over with sudo xcode-select -s /Applications/Xcode.app/Contents/Developer (change the path if you installed Xcode somewhere else).

2. Error AttributeError: Can't get attribute 'Mark' on <module 'ruamel.yaml.error' from ... when running spack install

   Some users are seeing this with Python 3.10 installed via Homebrew on macOS. Run export | grep SPACK_PYTHON to verify the Python version used, then run brew list to check if there are alternative Python versions available. Manually setting SPACK_PYTHON to a different version, for example via export SPACK_PYTHON=/usr/local/bin/python3.9, solves the problem.

3. Errors handling exceptions on macOS.

   A large number of errors related to handling exceptions thrown by applications was found when using default builds or Homebrew installations of mpich or openmpi, which use flat namespaces. With our spack version, mpich and openmpi are installed with a +two_level_namespace option that fixes the problem.

4. Errors such as Symbol not found: __cg_png_create_info_struct

   This can happen when trying to use the raster plotting scripts in fv3-jedi-tools. In that case, exporting DYLD_LIBRARY_PATH=/usr/lib/:$DYLD_LIBRARY_PATH can help. If git commands fail after this, you might need to verify where which git points to (Homebrew vs module) and unload the git module.

Ubuntu

1. The lmod version in Ubuntu 22.04 LTS breaks spack modules.

   Ubuntu 22.04 LTS will install lmod@6.6 from official APT repositories. Module files authored by spack use the depends_on directive that was introduced in lmod@7.0. Our site config instructions circumvent the issue by using tcl/tk environment modules. If you attempt to use lmod@6.6 you will get the following error:

   $ module load stack-python
   Lmod has detected the following error:  Unable to load module: python/3.10.8
   /home/ubuntu/spack-stack-1.3.1/envs/skylab-4/install/modulefiles/gcc/11.3.0/python/3.10.8.lua : [string "-- -*- lua -*-..."]:16: attempt to call global 'depends_on' (a nil value)