1 Introduction

Spack is a moving target and receives multiple commits per day.
Normally, HPCToolkit will build and run successfully with the latest
version of all of its prerequisite packages, but sometimes not. This
page covers the current known issues where HPCToolkit fails to build
with the latest version of spack.

Report problems to hpctoolkit-forum at rice dot edu. But before
reporting a problem, first try the versions recommended in the
packages.yaml file in the spack subdirectory of the
hpctoolkit repository. And always check the latest version of this file
on the hpctoolkit web site.

2 Current Issues

2.1 (2019-08-28) Cray front-end compilers

Spack compiler find is currently broken for detecting the
front-end compilers on Cray that HPCToolkit uses. Normally, you would
load a module for gcc and run spack compiler find and spack would
add that compiler to compilers.yaml, but this currently does not
work.

Workaround: If you have a working compiler: entry for a
front-end GNU compiler on Cray, then that will continue to work. If
not, then you will have to add one manually. For example, this is an
entry for the gcc/7.3.0 module on theta at ANL. Note that the
front-end operating_system is something like sles12 (not
cnl6), and the front-end target is x86_64 (not
mic_knl).

2.2 (2019-08-28) Cuda modules

Sometimes spack misreads the module: entry for an external
package in packages.yaml. This is infrequent and we haven’t
identified a clear pattern, but this has happened with the cuda modules
on cori at NERSC.

For example, with the cuda/10.1.168 module for the gpu version of
hpctoolkit on cori, you would use the following entry in
packages.yaml.

cuda:
modules:
cuda@10.1.168: cuda/10.1.168

This entry is supposed to work, but doesn’t. The correct cuda prefix is
actually /usr/common/software/cuda/10.1.168, but spack misreads
this as /usr. When this happens, hpctoolkit fails with error
messages showing that spack incorrectly uses the /usr path.
For example,

Workaround: In packages.yaml, replace the modules:
entry with a paths: prefix.

cuda:
paths:
cuda@10.1.168: /usr/common/software/cuda/10.1.168

2.3 (2019-08-19) Build-stage not writable

Spack has been reworking the build directory structure and the value for
build-stage in config.yaml is currently broken.

build_stage:
- $tempdir/spack-stage

The problem with this value is that the first user to run spack on this
machine will create the directory, owned by that user and thus not
writable by any other user. For every other user, spack install will
fail with:

==> Error: No accessible stage paths in:

Workaround: Change build-stage in config.yaml to
another directory that you can write to.

3 Recently Resolved Issues

3.1 (2019-06-06) Intel-xed and hpcviewer

Packages that use a spack resource (a second tar file) are currently
broken. This includes intel-xed (x86_64 only) and hpcviewer (all
platforms).

Fixed: This is now fixed in spack develop in commit
aca1bfdb6a64 on 2019-06-13.

4 General Problems

These are general problems that arise from time to time.

4.1 Unable to fetch

Sometimes spack fails to download the source file(s) for some package
and dies with a message similar to this.

This problem is usually temporary and the solution is to either wait a
few minutes or an hour and try again, or else download the file manually
and put it into a spack mirror.

4.2 New version breaks the build

Sometimes the latest version of some package breaks the build. This has
happened a couple of times where a new version of Boost has broken the
build for Dyninst. The solution is to revert the package to an earlier
version until the rest of the code catches up.

4.3 Spack core breaks the build

Sometimes but rarely, something in the spack core will change or break
the code in some package.py file. The solution is to look
through the spack git log and revert the repository to a recent commit
before the breakage.

5 Long Term Issues

5.1 Boost 1.68.0

Avoid boost version 1.68.0, it breaks the build for hpctoolkit. Version
1.70.0 works with the latest version of dyninst (10.1.0), or else 1.66.0
is good and works with all versions of dyninst.

5.2 Elfutils 0.176

Elfutils 0.176 requires glibc 2.16 or later (for aligned_alloc)
and won’t work with an older glibc, including RedHat or CentOS 6.x and
Blue Gene. On systems with an old glibc, use version 0.175.