Open giordano opened 7 months ago
I can confirm cp2k@2023.2 ... ^libxsmm@1.17
is built correctly, but I'm still confused: shouldn't spack already pick up the latest stable version automatically? Or we have to set the preferred
attribute to the 1.17 version of libxsmm to achieve that?
Was libxsmm@main
installed earlier and reused? Do you still get that version with --fresh
?
So, I ran into this within a much larger environment, it's possible libxsmm@main
was maybe required by some other packages and then reused. I confirm that with spack spec --fresh cp2k@2023.2
I do get ^libxsmm@1.17
as expected.
But I still think cp2k
shouldn't allow you to use ^libxsmm@main
since that combination seems to be broken? It's quite frustrating to discover these incompatibilities after several hours of building other packages.
I will add the exclusion it is the easiest.
Steps to reproduce the issue
Error message
The relevant bit of the error is
Error message
The undefined reference is to the symbol
libxsmm_dispatch_gemm_v2
, but libxsmm is linked with-l:libxsmmf.a -l:libxsmmext.a
, howeverdoesn't find anything. Note that the version of
libxsmm
that spack chose to use in this environment islibxsmm@main
, which sounds a bit fishy, as it is an in-development version of a package, which is a moving target. Is the missinglibxsmm_dispatch_gemm_v2
symbol a problem with this symbol being removed inlibxsmm@main
? If so, presumably this should be fixed by asking explicitly for the latest stable version of the dependency? I'm surprised Spack is choosing by default an@main
version though, I thought it'd favour stable versions?Information on your system
Additional information
spack-build-env.txt spack-build-out.txt
CC: @dev-zero @mtaillefumier (for cp2k); @hfp (for libxsmm)
General information
spack debug report
and reported the version of Spack/Python/Platformspack maintainers <name-of-the-package>
and @mentioned any maintainers