-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLAS misidentified as lp64 (it's ilp64) #206
Comments
@Jellby Could you please post the full CMake configure line you are using ? Also when you build/use an existing Reference LAPACK library, do you know if it was built with the ilp64 option |
It's a bit of an unorthodox build, I'm afraid... There's a file
which is compiled with:
Then, for GA:
And manually compiling the diagnostic file shows this:
while compiling |
We use the CMake LinAlg modules provided by @wavefunction91 and the modules only support the recommended Ref.
I think the way it's setup is if this test fails, the CMake BLAS discovery module determines it to be ILP64, otherwise LP64. See |
If you want to use ILP64 reference ScaLAPACK, you'll have to specify it manually (e.g. specify |
The point is the test does not "fail", but it should. The |
@Jellby Does this happen even after renaming |
@ajaypanyala That shouldn't matter, he's specifying it manually so it should just go through the validation. @Jellby Checking output would not be robust in general, for example, it's possible to trigger call-tree print in MKL with an environment variable while still giving the correct result. This is strange, if your BLAS library is ILP64, I can't see how it would give the correct results here |
@wavefunction91 It's not giving the correct result, the |
@Jellby Program aborts signal 0? That's not canonical at all, |
Yeah, it's a Fortran |
That's a good idea, I'll add that today and @ajaypanyala can update it here when its checked in |
@Jellby Could you please try |
It seems to work, but I'll have to change the infrastructure somewhat to be able to do a real test. |
@Jellby I have merged the latest fixes from @wavefunction91 to |
Somehow related to this (tell me if I should open a new issue): Now detection of LAPACK fails, apparently because: a) The order of libraries matters. This for a case where I pass b) |
About b), actually the error I get is something like https://stackoverflow.com/questions/30013845, where a single function is mentioned, and that might be arbitrary, but at least there's an explicit
And another suggestion. LAPACK is identified by searching for |
I would like to use a compiled Reference BLAS (and LAPACK), as part of another package. The libraries should be ilp64 and I add it as a required linalg component. However, I get, with CMake:
It seems https://github.com/GlobalArrays/ga/blob/develop/cmake/linalg-modules/util/ilp64_checker.c returns with:
but with return code of
0
, and the result checksum is never done.In https://github.com/Reference-LAPACK/lapack/blob/master/BLAS/SRC/xerbla.f, changing the
STOP
toSTOP 1
, causes at least the return code to be1
and the BLAS library being identified as ilp64.The text was updated successfully, but these errors were encountered: