if BLAS_ILP64 is #defined use 64-bit int

[evaleev]

BLAS_ILP64 is the preprocessor symbol defined by BLAS++

There is currently no introspection of int size (ILP vs LP). BLAS++'s introspection will not work when cross-compiling anyway so I think it's reasonable to require the user to define it appropriately.

Resolves #5

[wavefunction91]

@evaleev This is not generally safe, the ScaLAPACK library itself has to be introspected for LP/ILP64 to avoid unexpected problems (i.e. someone trying to link an ILP64 BLAS library to LP64 BLACS/ScaLAPACK). As the only (stock) ILP64 BLACS/ScaLAPACK library is MKL, this is a rather rare case (convincing ScaLAPACK/BLACS to compile ILP64 is tedious, even from source as the naming conventions are not consistent, rarely found in the wild).

The discovery modules already set ScaLAPACK_IS_LP64 when appropriate
https://github.com/wavefunction91/linalg-cmake-modules/blob/main/FindScaLAPACK.cmake#L134
https://github.com/wavefunction91/linalg-cmake-modules/blob/main/FindScaLAPACK.cmake#L140

Robust introspection (ala BLAS) should be done, but it generally requires running an MPI program, which is not generally possible at configure (on e.g. SLURM systems with MPI disabled on head-nodes). I do have the procedure set up, just have to figure out how to run it portably
https://github.com/wavefunction91/linalg-cmake-modules/blob/main/FindScaLAPACK.cmake#L191

The work around for this is that users will have to manually specify (non-MKL) ILP64 ScaLAPACK installations by ScaLAPACK_LIBRARIES and manually set ScaLAPACK_IS_LP64=FALSE

TL;DR BLAS ILP64 is not enough to ensure that everything is correct for a ScaLAPACK ILP64. We already have some variables floating around to handle this, we just haven't propagated them into the build system yet. I'll keep this open for now util I get around to fixing it (assuming that this patch already works for your purposes)

[evaleev]

Agree, but this is to ensure _necessary_ condition. If blas is ilp64, *only* ilp64 scalapack is going to work anyway (is that every bit the case?). This is not sufficient to validate scalapack api and its match with blas, only to ensure that is given ilp64 libs the things will work out of the box.

…

On Thu, Jan 7, 2021, 4:56 PM David Williams-Young ***@***.***> wrote: @evaleev <https://github.com/evaleev> This is not generally safe, the ScaLAPACK library itself has to be introspected for LP/ILP64 to avoid unexpected problems (i.e. someone trying to link an ILP64 BLAS library to LP64 BLACS/ScaLAPACK). As the only (stock) ILP64 BLACS/ScaLAPACK library is MKL, this is a rather rare case (convincing ScaLAPACK/BLACS to compile ILP64 is tedious, even from source as the naming conventions are not consistent, rarely found in the wild). The discovery modules <https://github.com/wavefunction91/linalg-cmake-modules> already set ScaLAPACK_IS_LP64 when appropriate https://github.com/wavefunction91/linalg-cmake-modules/blob/main/FindScaLAPACK.cmake#L134 https://github.com/wavefunction91/linalg-cmake-modules/blob/main/FindScaLAPACK.cmake#L140 Robust introspection (ala BLAS) should be done, but it generally requires running an MPI program, which is not generally possible at configure (on e.g. SLURM systems with MPI disabled on head-nodes). I do have the procedure set up, just have to figure out how to run it portably https://github.com/wavefunction91/linalg-cmake-modules/blob/main/FindScaLAPACK.cmake#L191 The work around for this is that users will have to manually specify (non-MKL) ILP64 ScaLAPACK installations by ScaLAPACK_LIBRARIES and manually set ScaLAPACK_IS_LP64=FALSE TL;DR BLAS ILP64 is not enough to ensure that everything is correct for a ScaLAPACK ILP64. We already have some variables floating around to handle this, we just haven't propagated them into the build system yet. I'll keep this open for now util I get around to fixing it (assuming that this patch already works for your purposes) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQXIZZVQJBKIQLFU4D4243SYYUYRANCNFSM4VNUWRXQ> .

[wavefunction91]

Addressed in #8