Just a topic to keep track of random spack errors/tips/fixes to save others time.
Was trying to run through the spack packaging tutorial and had this error:
$ spack install tutorial.mpileaks
==> Error: Package 'armpl-gcc' not found.
It was the result of some strange cruft in the spack caches, followed the advice in this comment to remove all instances of the package from ~/.spack/cache/providers/builtin-index.json and that did the trick.
There appears to be bugs with older versions of Python and Lustre when it comes to setting extended file attributes.
For example:
$ /bin/python3 --version
Python 3.6.8
<PID> setxattr("[...]/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.pack", "lustre.lov", "\320\v\321\v\1\0\0\0^:\1\0\0\0\0\0\254\353\0\300\4\0\0\0\0\0\20\0\1\0\0", 56, 0) = -1 EACCES (Permission denied)
<PID> setxattr("[...]/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.idx", "lustre.lov", "\320\v\321\v\1\0\0\0_:\1\0\0\0\0\0\254\353\0\300\4\0\0\0\0\0\20\0\1\0\0", 56, 0) = -1 EACCES (Permission denied)
On Gadi, try telling Spack to use a newer version of Python after the newer version is loaded:
$ module load python3/3.11.0
$ SPACK_PYTHON=/apps/python3/3.11.0/bin/python3 spack install oasis3-mct
I didn’t think the lustre filesystems on gadi supported extended file attributes at all. They work in $HOME directories though.
@dale.roberts would definitely know more.
Gadi’s filesystems absolutely support xattrs. The lustre.lov xattr is restricted, however, and can only be applied directly by root. Not that you’d want to apply that xattr anyway, it encodes lustre stripiing details and should never be directly manipulated.
I guess the newer version of whatever python package spack is using is either catching xattr errors and ignoring them when its sensible to do so, or has a smarter xattr filter.
With Python 3.11.0:
<PID> setxattr("[...]/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.pack", "lustre.lov", "\320\v\321\v\1\0\0\0\224I\0\0\0\0\0\0\261\353\0\300\4\0\0\0\0\0\20\0\1\0\0", 56, 0) = 0
<PID> setxattr("[...]/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.idx", "lustre.lov", "\320\v\321\v\1\0\0\0\225I\0\0\0\0\0\0\261\353\0\300\4\0\0\0\0\0\20\0\1\0\0", 56, 0) = 0
Good to know, thanks Dale. Sorry for the misinformation.
I recall mucking about with setfattr years ago and was told it wasn’t usable by non-root.
$ touch lala
$ setfattr -n foo -v bar lala
setfattr: lala: Operation not supported
Am I doing something wrong?
Ah, nope. You’re not. Turns out user-level xattrs are disabled on the lustre file systems. I wasn’t aware of that. That is different from not supporting xattrs at all though. Without system-level xattr support, ACLs don’t work.
@harshula I think what you’re seeing is whether whatever python module you’re using respects the $TMPDIR variable or not. Would be good to know what’s in the [...] part of the file path in those strace file paths. Insofar as I can tell, the only filesystem on Gadi to support user-level xattrs is jobfs.
Only thing that comes to mind is that TMPDIR=/scratch/$PROJECT/$USER/tmp on login nodes and TMPDIR=$PBS_JOBFS inside a PBS job. But strace should resolve that path fully without the environment variable, so do double check that python is respecting $TMPDIR, I’ve seen plenty of cases where it doesn’t.
@dale.roberts , Sorry, I just realised that I probably misunderstood your question. 
If your question is whether $TMPDIR is expanded to a real absolute path, the answer is yes. I was being opaque because I generally avoid putting internal system information on publicly accessible websites.
/scratch/<PROJECT>/<USER>/tmp/spack-stage/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.pack
/scratch/<PROJECT>/<USER>/tmp/spack-stage/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.idx
@harshula All good! looks like you’ve discovered something really interesting there. I’m curious as to why you get EACCES instead of EOPNOTSUPP in python 3.6, and why it works at all in python 3.11. Even on /jobfs I get EOPNOTSUPP when trying to set setfattr -n lustre.lov. Oh well, as long as spack works that can be a mystery for another time.
Following up what @harshula found, I was getting this error:
==> Error: variant "ensurepip" not found in package "python"
when using the system python. Loading the python3/3.11.0 module and invoking it as below fixed this error.
SPACK_PYTHON=/apps/python3/3.11.0/bin/python3 spack install oasis3-mct
FYI for anyone with a seemingly random error like that, with very little in the way of information about why it occurred.
EDIT: Now I’m not sure this was the problem. I think the issue was the external python packages in ~/.spack/packages.yaml
python:
externals:
- spec: python@3.10.4+bz2+ctypes+dbm+ensurepip+lzma+nis+pyexpat~pythoncmd+readline+sqlite3+ssl+tix+tkinter+uuid+zlib
prefix: /apps/python3/3.10.4
modules:
- python3/3.10.4
- intel-mkl/2021.4.0
- spec: python@2.7.18+bz2+ctypes+dbm+ensurepip+nis+pyexpat~pythoncmd+readline+sqlite3+ssl~tix~tkinter+uuid+zlib
prefix: /usr
- spec: python@3.6.8+bz2+ctypes+dbm+ensurepip+lzma+nis+pyexpat~pythoncmd+readline+sqlite3+ssl~tix~tkinter+uuid+zlib
prefix: /usr
buildable: false
They all have ensurepip as variants in the spec. This was removed as a valid variant. The solution was to remove that variant from the spec in the external python packages, e.g.
python:
externals:
- spec: python@3.11.0+bz2+crypt+ctypes+dbm+lzma+nis+pyexpat~pythoncmd+readline+sqlite3+ssl+tix+tkinter+uuid+zlib
prefix: /apps/python3/3.11.0
buildable: false
The error message I was receiving with Python 3.6.8 was:
==> Error: Error: [('oasis3-mct/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.pack', '/scratch/<PROJECT>/<USER>/tmp/spack-stage/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.pack',
"[Errno 13] Permission denied: '/scratch/<PROJECT>/<USER>/tmp/spack-stage/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.pack'"), ('oasis3-mct/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.idx', '/scratch/<PROJECT>/<USER>/tmp/spack-stage/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.idx',
"[Errno 13] Permission denied: '/scratch/<PROJECT>/<USER>/tmp/spack-stage/spack-stage-oasis3-mct-5e57b1aa40840adb6d6747d475dabadab5d9d6fb-5u3zvtlhkeppjiqtsy244fqc7nilijud/spack-src/.git/objects/pack/pack-7fd5c57e84bad70a131e1b57b474ea6666906c55.idx'")]
Python 3.7.4 worked:
module load python3/3.7.4
SPACK_PYTHON=/apps/python3/3.7.4/bin/python3 spack install oasis3-mct
1 Like
If you see this error installing parallelio with Spack 0.19:
==> Installing parallelio-2.5.9-eikggbrfazzq5qxxqpfxehpkcqwxhrcs
==> No binary for parallelio-2.5.9-eikggbrfazzq5qxxqpfxehpkcqwxhrcs found: installing from source
==> Using cached archive: <SPACK_GIT_REPO>/var/spack/cache/_source-cache/archive/e5/e5dbc153d8637111de3a51a9655660bf15367d55842de78240dcfc024380553d.tar.gz
==> Using cached archive: <SPACK_GIT_REPO>/var/spack/cache/_source-cache/git//PARALLELIO/genf90.git/genf90_200608.tar.gz
==> Warning: Fetching from mirror without a checksum!
This package is normally checked out from a version control system, but it has been archived on a spack mirror. This means we cannot know a checksum for the tarball in advance. Be sure that your connection to this mirror is secure!
==> Moving resource stage
source: <TMPDIR>/spack-stage/resource-genf90-eikggbrfazzq5qxxqpfxehpkcqwxhrcs/spack-src/
destination: <TMPDIR>/spack-stage/spack-stage-parallelio-2.5.9-eikggbrfazzq5qxxqpfxehpkcqwxhrcs/spack-src/genf90
Reversed (or previously applied) patch detected! Assume -R? [n]
Apply anyway? [n]
2 out of 2 hunks ignored -- saving rejects to file CMakeLists.txt.rej
==> Patch <SPACK_GIT_REPO>/var/spack/repos/builtin/packages/parallelio/gfortran.patch failed.
==> Error: ProcessError: Command exited with status 1:
'/usr/bin/patch' '-s' '-p' '1' '-i' '<SPACK_GIT_REPO>/var/spack/repos/builtin/packages/parallelio/gfortran.patch' '-d' '.'
It’s likely because this commit made it into Spack 0.19:
commit 60997a7bc34616406e331a2919deec0bd36893a3
Author: Jim Edwards <jedwards@ucar.edu>
Date: Mon Sep 19 15:45:40 2022 -0600
add pio2_5_9 to spack package (#32716)
and the following commit did not:
commit 790bd175e01466bd88b83b3d275d38654e428e95
Author: Jim Edwards <jedwards@ucar.edu>
Date: Sat Nov 19 03:50:01 2022 -0700
parallelio: update package to use mpi-serial, add extra module info (#33153)
It seems that Spack needed to apply a patch to the parallelio source code, however, that patch had been included in parallelio 2.5.9. Applying the following patch should avoid the error:
diff --git a/var/spack/repos/builtin/packages/parallelio/package.py b/var/spack/repos/builtin/packages/parallelio/package.py
index 91c2e340d5..f8d432ef83 100644
--- a/var/spack/repos/builtin/packages/parallelio/package.py
+++ b/var/spack/repos/builtin/packages/parallelio/package.py
@@ -36,7 +36,7 @@ class Parallelio(CMakePackage):
depends_on("parallel-netcdf", type="link", when="+pnetcdf")
# Allow argument mismatch in gfortran versions > 10 for mpi library compatibility
- patch("gfortran.patch", when="+fortran %gcc@10:")
+ patch("gfortran.patch", when="@:2.5.8 +fortran %gcc@10:")
resource(name="genf90", git="https://github.com/PARALLELIO/genf90.git", tag="genf90_200608")
1 Like
FYI, Today i was able to do (with module load gcc/12.2.0):
$ python3 --version; spack install libaccessom2
Python 3.6.8
...
==> Installing oasis3-mct-spack-build-xgoxmyvzr45n76jwov66xsgalydfljul
==> No binary for oasis3-mct-spack-build-xgoxmyvzr45n76jwov66xsgalydfljul found: installing from source
==> No patches needed for oasis3-mct
==> oasis3-mct: Executing phase: 'build'
==> oasis3-mct: Executing phase: 'install'
==> oasis3-mct: Successfully installed oasis3-mct-spack-build-xgoxmyvzr45n76jwov66xsgalydfljul
Fetch: 3.40s. Build: 45.14s. Total: 48.54s.
...
==> Installing libaccessom2-spack-build-72vu37mtomnfoygxwnehys6lj3xgfs4z
==> No binary for libaccessom2-spack-build-72vu37mtomnfoygxwnehys6lj3xgfs4z found: installing from source
==> No patches needed for libaccessom2
==> libaccessom2: Executing phase: 'cmake'
==> libaccessom2: Executing phase: 'build'
==> libaccessom2: Executing phase: 'install'
==> libaccessom2: Successfully installed libaccessom2-spack-build-72vu37mtomnfoygxwnehys6lj3xgfs4z
Fetch: 4.88s. Build: 17.74s. Total: 22.62s.
So, there may be conditions that allow the use of Python 3.6.8 without a problem.
1 Like
I’ve been trying to build ESMF with @Aidan’s help. Dependencies seem to all be built successfully, but it gets killed in the build phase for esmf.
In the first several attempts it simply said “killed”, but now it’s giving a detailed error log:
/scratch/v45/aek156/tmp/spack-stage/spack-stage-esmf-8.3.1-fdatj3fq6vud74da66hhs3m4hbkdpeym/spack-build-out.txt
This is the recipe I followed:
cd /g/data/v45/aek156
git clone https://github.com/spack/spack.git
cd spack
git checkout remotes/origin/releases/v0.19
module unload conda # to avoid clashes with module spack/config
module use /g/data/access/spack/modules # requires membership of access group
module load spack/config # contains just enough configuration to standardise compilers, MPI and external packages but use your own spack tree
. share/spack/setup-env.sh # see explanation https://forum.access-hive.org.au/t/shared-access-spack-configuration/227
spack install esmf %intel@2021.6.0 ^openmpi@4.1.4 # killed
As usual permissions problems:
$ ls -lhd /scratch/v45/aek156/tmp/spack-stage/
drwx------ 5 aek156 v45 4.0K Jan 18 09:52 /scratch/v45/aek156/tmp/spack-stage/
In any case, killed usually means you’ve run afoul of some limits on interactive jobs: too much memory used, or some time limit exceeded.
I was planning to take another look at this, if you want to wait until I’ve done so I might be able to find a resolution.
thanks, I think I’ve fixed perms, sorry about that. Not sure about memory, but time use was
real 16m56.127s
user 15m2.183s
sys 12m19.126s
So it worked for me (such an annoying phrase)
$ spack install esmf@8.2.0 %intel@2021.6.0 ^openmpi@4.1.4
[+] /usr (external libxml2-2.9.7-4z3rhzq6kupydi7arpas3tj63weosukw)
==> cmake@3.24.2 : has external module in ['cmake/3.24.2']
[+] /apps/cmake/3.24.2 (external cmake-3.24.2-tr5446kifdb2z2ygjannnsdf5st2hqvl)
==> openmpi@4.1.4 : has external module in ['openmpi/4.1.4']
[+] /apps/openmpi/4.1.4 (external openmpi-4.1.4-yvq3ppqr2udizcor23x7j2x6qmd6xuxs)
[+] /usr (external pkgconf-1.4.2-vqr4piq7hjmtknwkpijthk2c6iehgcfq)
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/zlib-1.2.13-qbwlozg4cobphkvyaizqmi47xw3ara5o
[+] /usr (external m4-1.4.18-6lm7an562pgot5yidv7coxy2hp5yrknh)
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/zstd-1.5.2-hvjxleot65gcc6xeciefjgeimov4i72l
[+] /usr (external perl-5.26.3-4lnqmockddbrrcesq3m2d6ikkkwsod5l)
==> Installing libiconv-1.16-nsqdn3qff5udwynki2uizoukrxxhgkmm
==> No binary for libiconv-1.16-nsqdn3qff5udwynki2uizoukrxxhgkmm found: installing from source
==> Fetching https://mirror.spack.io/_source-cache/archive/e6/e6a1b1b589654277ee790cce3734f07876ac4ccfaecbee8afa0b649cf529cc04.tar.gz
==> No patches needed for libiconv
==> libiconv: Executing phase: 'autoreconf'
==> libiconv: Executing phase: 'configure'
==> libiconv: Executing phase: 'build'
==> libiconv: Executing phase: 'install'
==> libiconv: Successfully installed libiconv-1.16-nsqdn3qff5udwynki2uizoukrxxhgkmm
Fetch: 0.20s. Build: 2m 39.55s. Total: 2m 39.74s.
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/libiconv-1.16-nsqdn3qff5udwynki2uizoukrxxhgkmm
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/hdf5-1.12.2-xmsywdnkwqsjl5t3qqcngqeztbeybznn
==> Installing parallel-netcdf-1.12.3-xty6sc5nvkq6i4geyjlxzlai4enmeqmw
==> No binary for parallel-netcdf-1.12.3-xty6sc5nvkq6i4geyjlxzlai4enmeqmw found: installing from source
==> Fetching https://mirror.spack.io/_source-cache/archive/43/439e359d09bb93d0e58a6e3f928f39c2eae965b6c97f64e67cd42220d6034f77.tar.gz
==> No patches needed for parallel-netcdf
==> parallel-netcdf: Executing phase: 'autoreconf'
==> parallel-netcdf: Executing phase: 'configure'
==> parallel-netcdf: Executing phase: 'build'
==> parallel-netcdf: Executing phase: 'install'
==> parallel-netcdf: Successfully installed parallel-netcdf-1.12.3-xty6sc5nvkq6i4geyjlxzlai4enmeqmw
Fetch: 0.16s. Build: 8m 43.97s. Total: 8m 44.12s.
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/parallel-netcdf-1.12.3-xty6sc5nvkq6i4geyjlxzlai4enmeqmw
==> Installing xerces-c-3.2.3-hsf7je75hznzdp5b66f32u4b7cvbjasv
==> No binary for xerces-c-3.2.3-hsf7je75hznzdp5b66f32u4b7cvbjasv found: installing from source
==> Fetching https://mirror.spack.io/_source-cache/archive/45/45c2329e684405f2b8854ecbddfb8d5b055cdf0fe4d35736cc352c504989bbb6.tar.bz2
==> No patches needed for xerces-c
==> xerces-c: Executing phase: 'autoreconf'
==> xerces-c: Executing phase: 'configure'
==> xerces-c: Executing phase: 'build'
==> xerces-c: Executing phase: 'install'
==> xerces-c: Successfully installed xerces-c-3.2.3-hsf7je75hznzdp5b66f32u4b7cvbjasv
Fetch: 0.13s. Build: 2m 53.58s. Total: 2m 53.72s.
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/xerces-c-3.2.3-hsf7je75hznzdp5b66f32u4b7cvbjasv
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/netcdf-c-4.9.0-t5vmcraajgpax4rnsuceljayogf5zmdb
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/netcdf-fortran-4.6.0-l6jywjuwrnqdfheafvxrnslkvrafhpr7
==> Installing esmf-8.2.0-wqejj4npdl4so6zql3xzamelwwp3znhd
==> No binary for esmf-8.2.0-wqejj4npdl4so6zql3xzamelwwp3znhd found: installing from source
==> Fetching https://mirror.spack.io/_source-cache/archive/36/3693987aba2c8ae8af67a0e222bea4099a48afe09b8d3d334106f9d7fc311485.tar.gz
==> No patches needed for esmf
==> esmf: Executing phase: 'edit'
==> esmf: Executing phase: 'build'
==> esmf: Executing phase: 'install'
==> esmf: Successfully installed esmf-8.2.0-wqejj4npdl4so6zql3xzamelwwp3znhd
Fetch: 2.78s. Build: 32m 12.75s. Total: 32m 15.53s.
[+] /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/esmf-8.2.0-wqejj4npdl4so6zql3xzamelwwp3znhd
A few things to note:
- I used the
spack/configmodule so our configurations should be pretty much the same (spackdoes tend to write things into~/.spackbut you’ve not used it before and I have a minimal amount in there, nothing that would interfere) - My build found the external packages fine (
cmake,openmpi,perl,pkgconfig,m4,libxml) which from memory yours did not:
$ spack find -dLfp esmf
-- linux-rocky8-cascadelake / intel@2021.6.0 --------------------
wqejj4npdl4so6zql3xzamelwwp3znhd esmf@8.2.0%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/esmf-8.2.0-wqejj4nppdl4so6zql3xzamelwwp3znhd
4z3rhzq6kupydi7arpas3tj63weosukw libxml2@2.9.7%intel /usr
t5vmcraajgpax4rnsuceljayogf5zmdb netcdf-c@4.9.0%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/netcdf-c-4.9.0-t5vmmcraajgpax4rnsuceljayogf5zmdb
xmsywdnkwqsjl5t3qqcngqeztbeybznn hdf5@1.12.2%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/hdf5-1.12.2-xmsywdnnkwqsjl5t3qqcngqeztbeybznn
tr5446kifdb2z2ygjannnsdf5st2hqvl cmake@3.24.2%intel /apps/cmake/3.24.2
vqr4piq7hjmtknwkpijthk2c6iehgcfq pkgconf@1.4.2%intel /usr
6lm7an562pgot5yidv7coxy2hp5yrknh m4@1.4.18%intel /usr
hvjxleot65gcc6xeciefjgeimov4i72l zstd@1.5.2%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/zstd-1.5.2-hvjxleott65gcc6xeciefjgeimov4i72l
l6jywjuwrnqdfheafvxrnslkvrafhpr7 netcdf-fortran@4.6.0%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/netcdf-fortran-4.6..0-l6jywjuwrnqdfheafvxrnslkvrafhpr7
yvq3ppqr2udizcor23x7j2x6qmd6xuxs openmpi@4.1.4%intel /apps/openmpi/4.1.4
xty6sc5nvkq6i4geyjlxzlai4enmeqmw parallel-netcdf@1.12.3%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/parallel-netcdf-1.112.3-xty6sc5nvkq6i4geyjlxzlai4enmeqmw
4lnqmockddbrrcesq3m2d6ikkkwsod5l perl@5.26.3%intel /usr
hsf7je75hznzdp5b66f32u4b7cvbjasv xerces-c@3.2.3%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/xerces-c-3.2.3-hsf77je75hznzdp5b66f32u4b7cvbjasv
nsqdn3qff5udwynki2uizoukrxxhgkmm libiconv@1.16%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/libiconv-1.16-nsqdnn3qff5udwynki2uizoukrxxhgkmm
qbwlozg4cobphkvyaizqmi47xw3ara5o zlib@1.2.13%intel /scratch/tm70/aph502/opt/spack/linux-rocky8-cascadelake/intel-2021.6.0/zlib-1.2.13-qbwlozgg4cobphkvyaizqmi47xw3ara5o
- I built
cmake@8.2because that is what I’d successfully done before. I will now try 8.3.1 - Your build was indeed killed for exceeding resources (I’d guess). From your log file:
icpc: error #10106: Fatal error in /apps/intel-oneapi/compiler/2022.1.0/linux/bin/intel64/../../bin/intel64/mcpcom, terminated by kill signal
compilation aborted for /scratch/v45/aek156/tmp/spack-stage/spack-stage-esmf-8.3.1-fdatj3fq6vud74da66hhs3m4hbkdpeym/spack-src/src/Infrastructure/Mesh/src/ESMCI_Mesh_GToM_Glue.C (code 1)