Status of MKL packages in debian - porting to Gentoo

[Aisha Tammy]

On 10/25/20 9:27 AM, Mo Zhou wrote:
> Hi Aisha,
> 
> On Sun, Oct 25, 2020 at 08:55:17AM -0400, Aisha Tammy wrote:
>> Actually this should not be a problem.
>> The blas-lapack switch only changed paths in the runtime ld.so search
>> file /etc/ld.so.conf.
>> So the compile time linker actually only builds against the
>> reference blas/lapack libraries.
> 
> Ah, thanks for the confirmation. I have to admit that I forgot some
> details. But anyway it seems that I have done the right thing for Gentoo
> when writing that blas/lapack switching mechanism.  :-)
> 
> Currently Debian's MKL package only register	s libmkl_rt.so as a
> candidate for libblas.so.3, and we can guarantee that all packages
> requiring libblas.so.3 are built against the standard netlib.
> 
Indeed, the mechanism is working really nicely, so thanks a lot for
that :)

I managed to get MKL to work and used a lot of the debian packages for
referencing, I've kept the hierarchies same so that users and packagers
can expect a consistent interface :)

Following up with a secondary topic, on blas64 and lapack64.
Netlib hasn't specified any details about how C/BLAS and LAPACK/E
API is named when using 64bit integer storage.
Presumably the symbol names shouldn't be changed, which will make them
incompatible to be linked simultaneously.
I've seen that there are blas64, lapack64 and lapacke64 but no cblas64.
Is there any specific reasoning behind the cblas64 not being present?
I've managed to get the other three 64 packages to build but I'm still
stuck on the cblas64.
AFAIK its because their code doesn't have any lapack_int like variable
to change function signatures.
Also, I see some packages providing a cblas64.h header (like blis) but
I am not exactly sure what that entails.
Given the previous non existence of a cblas64 reference implementation
I am curious what this is.

Thanks a lot,
Aisha