Closed puneetmatharu closed 1 year ago
Closing as this currently does not work the desired way on Linux with the way ScaLAPACK is currently implemented.
Now I see the issue. I am about to implement Git submodules in MUMPS. I just got tied up on another project. I plan to have this fixed by the end of November.
Then, right, there is no need to propagate as MUMPS will find Lapack and not build it or need to pass to Scalapack as it will be one project.
MUMPS is currently locked to Scalapack 2.2.1.6, which was before Git submodules were implemented in Scalapack. However as I say, soon MUMPS will also use Git submodules and then this PR wouldn't be needed anyway.
I think I remember there being a check (possibly in ScaLAPACK?) to see if it was the top-level project and if it wasn't then it would demand that LAPACK be supplied to it from the parent project. Is this what you're referring to? If so, I'm not sure that will work if ScaLAPACK will be built/installed via ExternalProject (instead of FetchContent); I think ScaLAPACK will believe at configure-time that it is the root project.
If it helps, I came up with a simple patch for ScaLAPACK (by stealing what you had already done in MUMPS 😛):
With the combination of these changes, the build works as expected.
Issue
I'm currently building MUMPS with my own LAPACK installation (OpenBLAS), specified by the CMake argument
-DLAPACK_ROOT
. During configuration, MUMPS correctly detects the OpenBLAS installation that I direct it to. However, it does not tell ScaLAPACK about this argument and thus ScaLAPACK mistakenly locates the wrong LAPACK installation.Contribution
This PR updates the CMake arguments passed to ScaLAPACK; if
LAPACK_ROOT
is passed to MUMPS, it will also be provided to ScaLAPACK.