[gentoo-science] On BLAS and LAPACK int64 ABI

[Benda Xu <heroxbd@gentoo.org>]

Hi,

This discussion emerged from https://github.com/gentoo/sci/pull/876.  I
am taking it here for better future reference.

cdluminate:
> It would be problematic to provide int64 ABI/API through libblas.so or
> liblapack.so since that would lead to a mess with the int32
> ABI/API. Adding the int64 USE flags to existing packages will make it
> hard to write ebuilds for users who want e.g. both int32 and int64
> openblas at the same time. My personal recommendation is to provide a
> new set of packages, say eselect-{blas64,lapack64} + sci-libs/lapack64,
> which are clearly isolated with the int32 ones. These new packages
> should change SONAMEs into say libblas64.so and liblapack64.so. This is
> the same as what I'm doing for Debian's 64bit-indexing BLAS/LAPACK
> packages.

heroxbd:
> We can make int64 as a use flag and by enabling it we install 2 sets of
> libraries: libblas.so and libblas64.so. What do you think?

kiwifb:
> I know why you want that @heroxbd - you want to avoid ebuild
> duplication. On the face of it it is less ebuilds to maintain in
> exchange of more complex ebuilds. However I think it would still be
> wise to have at least separate virtuals - that means dependencies on
> int32 and int64 are completely separate and allow a different set of
> implementations without impinging on each other.

> Whether to go for doubling the ebuilds or making them more complex is
> up to the maintainer. And we have to deal with the headers in any
> case.

cdluminate:
> I agree with @kiwifb . At least we need
> virtual/{blas64,cblas64,lapack64,lapacke64}. For the implementations
> we could introduce two new USE flags: int32 and int64, where each of
> them could trigger a separate full build, and int32 is enabled by
> default. Same for the eselect packages.

I agree with int32 and int64 USE flags. but int32 and int64 is too
simple and misleading, how about index_int32 and index_int64?  They are
named after python_targets_python3_7.

Virtual/blas could do the same: virtual/blas[index_int32,index_int64].

Yours,
Benda