Add support for the 64-bit integer interface (ilp64)

[steabert]

Hi!

It's quite common in high-performance computing to reach sizes where 32-bit integers no longer cut it. As such, most people usually compile everything they can with ilp64 interface instead of lp64. I wonder what would be needed to get this support into blas-lapack-rs?

Usually the real PITA with C/C++ and Fortran is if ilp64/lp64 get mixed between the application and libraries, or between different libraries. The fact that you seem to offer the very neat -src packages as well could be a fantastic way to avoid incompatibilities. I'm no cargo expert by any length, but it seems it would be possible to make sure to match up features between dependencies?

There is an issue on the ndarray crate that has been open for about 4 years now, it would be nice to get that supported: rust-ndarray/ndarray#133.
I forked both openblas-src and cblas-sys to take a quick look at what would be needed, but I'm lacking the skills to get most out of the cargo features (and how to enforce compatibility).

[IvanUkhov]

Hi, I’m not that familiar with this compilation option of OpenBLAS. Is there some description of which functions it affects and in what way? I briefly searched and came across INTERFACE64. Apparently, it affects the naming of the exported symbols. It is also not clear whether it concerns BLAS and/or CBLAS and/or LAPACK and/or LAPACKE.

[steabert]

The option will set blasint (which is used for all interfaces) to long or long long (depending on platform). I've written a longer comment on rust-ndarray/ndarray#133.

[IvanUkhov]

That part I understand. I’m more referring to which subset of functions it is applied to and whether there are any naming changes, such as those suffixes I mentioned.

[steabert]

As far as I can tell from cblas.h, it's applied to all functions. When using plain make, the library name is the same, but it seems that when compiling with cmake, there is actually a change in name for the library and it gets a _64 suffix.