Skip to content
Peter Scheibel edited this page Jan 12, 2022 · 5 revisions

Attendees

  • Peter Scheibel
  • Massimiliano Culpo
  • Tammy Dahlgren
  • Greg Becker
  • Mark Krentel
  • Nick Sly (LANL)

Agenda

  • Spack not bootstrapping Clingo on perlmutter: https://github.com/spack/spack/issues/28315
    • Error with patchelf, is bootstrapping from sources working?
    • Mark: spack compiler find is not finding any compilers on the frontend node on Perlmutter
    • Mark: will try allowing the bootstrapping to proceed with from-source installation

Possible agenda items

  • Multiple providers of same virtual package
    • Case 1: we want blas from X and lapack from Y
    • Case 2: we actually want several instances of the same virtual (e.g. to run different instances of MPI for the same root)
  • Possibly revisit: https://github.com/spack/spack/discussions/24966
    • Concerning improvements to spack develop
  • Harmen (not sure if I can join): there are packages like libblastrampoline / libmpitrampoline which provide a blas / lapack / mpi interface to link to, and forwards calls to an actual blas / lapack / mpi provider lib. E.g. julia uses it to link to a blas interface for its binary deps, allowing the user to switch blas provider at runtime, avoiding abi issues. The problem is Spack only allows one provider per dag, but these packages both provides the virtual and depends on the virtual. How do we deal with this "composition" type of pattern? I was thinking: maybe we can relax unique provider per dag to unique provider per subgraph connected through link type deps? Then libblastrampoline can provide blas, and depend on blas as a run-type dependency.
Clone this wiki locally