Random spack errors/tips/fixes

Technical spack
41

3 posts were split to a new topic: Detached head error when using spack to build ESM1.6

44

@inh599 @TommyGatti I’m moving your conversation to its own topic because this isn’t about a spack issue. It’s a help request about using our tools and user guides around spack and should come in as its own topic. And then we can monitor it using our user support process, otherwise we can’t.

1 Like
45

If you’re re-building a package repeatedly spack should find and re-use dependencies that were build before. In some cases spack might decide it wants to rebuild a dependency, this could be due to a change in the spack package, maybe a change in dependency lower down the hierarchy, or it may just be a bug.

You can tell spack to use an installed version of the package by specify the spack package hash instead of the package dependency. e.g. the environment below is building the tar package and specifying bzip@1.0.8 as a dependency:

spack:
  specs:
  - tar
  packages:
    tar:
      require:
        - "@1.34"
        - "%gcc@14.1.0"
    bzip2:
      require:
        -"'@1.0.8"

To enforce re-use of the compiled bzip2 package the requirement has been commented out and the spack hash of the package specified in the spec:

spack:
  specs:
  - tar ^/kpv36ze
  packages:
    tar:
      require:
        - "@1.34"
        - "%gcc@14.1.0"
    # bzip2:
    #   require:
    #     -"'@1.0.8" #  /kpv36ze
46

The way to specify a compiler has changed in Spack v1. Now a specific compiler can be specified for different programming languages.

Spack v0.22

     all:
       require:
         - '%intel@2021.10.0'
         - 'target=x86_64'

Spack v1

    fortran:
      require:
        - 'intel-oneapi-compilers-classic@2021.10.0'

    fortran:
      require:
        - 'intel-oneapi-compilers@2025.2.0'