Gentoo Archives: gentoo-science

From: Benda Xu <heroxbd@g.o>
To: gentoo-science@l.g.o
Subject: [gentoo-science] On BLAS and LAPACK int64 ABI
Date: Thu, 11 Jul 2019 13:59:28
Message-Id: 87sgrcisef.fsf@proton.d.airelinux.org
1 Hi,
2
3 This discussion emerged from https://github.com/gentoo/sci/pull/876. I
4 am taking it here for better future reference.
5
6 cdluminate:
7 > It would be problematic to provide int64 ABI/API through libblas.so or
8 > liblapack.so since that would lead to a mess with the int32
9 > ABI/API. Adding the int64 USE flags to existing packages will make it
10 > hard to write ebuilds for users who want e.g. both int32 and int64
11 > openblas at the same time. My personal recommendation is to provide a
12 > new set of packages, say eselect-{blas64,lapack64} + sci-libs/lapack64,
13 > which are clearly isolated with the int32 ones. These new packages
14 > should change SONAMEs into say libblas64.so and liblapack64.so. This is
15 > the same as what I'm doing for Debian's 64bit-indexing BLAS/LAPACK
16 > packages.
17
18 heroxbd:
19 > We can make int64 as a use flag and by enabling it we install 2 sets of
20 > libraries: libblas.so and libblas64.so. What do you think?
21
22 kiwifb:
23 > I know why you want that @heroxbd - you want to avoid ebuild
24 > duplication. On the face of it it is less ebuilds to maintain in
25 > exchange of more complex ebuilds. However I think it would still be
26 > wise to have at least separate virtuals - that means dependencies on
27 > int32 and int64 are completely separate and allow a different set of
28 > implementations without impinging on each other.
29
30 > Whether to go for doubling the ebuilds or making them more complex is
31 > up to the maintainer. And we have to deal with the headers in any
32 > case.
33
34 cdluminate:
35 > I agree with @kiwifb . At least we need
36 > virtual/{blas64,cblas64,lapack64,lapacke64}. For the implementations
37 > we could introduce two new USE flags: int32 and int64, where each of
38 > them could trigger a separate full build, and int32 is enabled by
39 > default. Same for the eselect packages.
40
41 I agree with int32 and int64 USE flags. but int32 and int64 is too
42 simple and misleading, how about index_int32 and index_int64? They are
43 named after python_targets_python3_7.
44
45 Virtual/blas could do the same: virtual/blas[index_int32,index_int64].
46
47 Yours,
48 Benda

Replies

Subject Author
Re: [gentoo-science] On BLAS and LAPACK int64 ABI Mo Zhou <lumin@××××××.org>