Correctly find LAPACK and link against it#999
Conversation
|
Hmm... this seems to further complicate our installs. I noticed that we make a direct LAPACK call instead of invoking it through |
No. This is fixes link-time problem, when the build process either does not know about LAPACK or uses a wrong one (different name mangling). |
|
Another way for "fix" this is to redo the |
Right. I think using SLEPc might be the better thing to do (we already install it as part of PETSc), and I've been updating my SLEPc eigen-solver commit anyway. Although, these are small matrices, so LAPACK is probably what we really want. It just hate to depend on it directly. |
Yeah, that's another way. However we don't have SLEPc in the upstream yet. You could split your PR to just add SLEPc first, then we patch |
BLAS/LAPACK is always problematic. Machines have multiple versions, different name mangling. Just a huge PITA to deal with... |
|
Installing OpenBLAS on MacOS was an absolute nightmare. Stock LAPACK works, but will require a FORTRAN compiler again. @andrsd Can you try this patch and see if it works for you? It worked on my mac using both the Accelerate framework and using the PETSc LAPACK libraries. I haven't tested on Linux yet. |
PETSc is built with BLAS/LAPACK support, but it treats it as a private library. That means the libraries used when building PETSc are not exposed to the PETSc client code. Suprisingly there is no issue on linux. However, on a Mac and in a conda environment there might be multiple installations of BLAS/LAPACK (Apple supplies one and conda can install additional ones). Then, it can happen that OpenSn tries to link against the wrong version which may have different name mangling. This patch adds support at the cmake level to find LAPACK (this shows now in the configure output). However, this by itself may not be enough to get a successful build. A cmake variable `BLA_VENDOR` can be set on the command line to hint cmake with BLAS/LAPACK to use. Typically, users should point to the BLAS/LAPACK used by PETSc if multiple libraries are installed.
andrsd
force-pushed
the
fix-lapack
branch
2 times, most recently
from
1796842 to
d67d099
Compare
2 participants
PETSc is built with BLAS/LAPACK support, but it treats it as a private library. That means the libraries used when building PETSc are not exposed to the PETSc client code. Suprisingly there is no issue on linux. However, on a Mac and in a conda environment there might be multiple installations of BLAS/LAPACK (Apple supplies one and conda can install additional ones).
Then, it can happen that OpenSn tries to link against the wrong version which may have different name mangling. This patch adds support at the cmake level to find LAPACK (this shows now in the configure output). However, this by itself may not be enough to get a successful build. A cmake variable
BLA_VENDORcan be set on the command line to hint cmake with BLAS/LAPACK to use. Typically, users should point to the BLAS/LAPACK used by PETSc if multiple libraries are installed.