Closed adamjstewart closed 8 years ago
this is very weird, why would any package depend simultaneously on (system?) libblas and liblapack and then also on libatlas?
Atlas is one of the implementation of Blas and Lapack routines (similar to OpenBlas, -framework Accelerate on macOS, MKL and alike). So spack is right that it forbids to use both Openblas and Atlas at the same time.
I would suggest to contant developers to ask what is the rationale behind that strange dependency.
i find this link to be a good description of blas, lapack and other related routines http://glennklockwood.blogspot.de/2014/02/quantum-espresso-compiling-and-choice.html
But atlas provides libblas.so, liblapack.so, and libatlas.so right? What is libatlas.so for? I actually got the package working without Atlas, so it must not be crucial.
Sorry, but i don't know specifics of how atlas splits the resulting libraries.
if you made it work, perhaps one can close the issue.
Yeah, I think this can be closed. Must just be that the developers didn't word their documentation very well. I can't even remember what package I was working on at the time.
I'm working on a package that requires libblas.so, liblapack.so, and libatlas.so. It specifically recommends using OpenBLAS for BLAS/LAPACK. However, I would also need to depend on ATLAS to get libatlas.so, right? Spack doesn't currently allow this, since you can't have multiple providers for the same virtual dependency. I tried specifically depending on openblas and atlas instead of blas and lapack, but that didn't help. Am I doing something wrong, or do I just not understand how blas, lapack, and atlas are related?