1 |
On Thu, 2019-06-13 at 00:15 -0700, Mo Zhou wrote: |
2 |
> Hi Gentoo devs, |
3 |
> |
4 |
> I redesigned the solution for BLAS/LAPACK runtime switching. |
5 |
> New solution is based on eselect+ld.so.conf . See following. |
6 |
> |
7 |
> > Goal |
8 |
> > ---- |
9 |
> > |
10 |
> > * When a program is linked against libblas.so or liblapack.so |
11 |
> > provided by any BLAS/LAPACK provider, the eselect-based solution |
12 |
> > will allow user to switch the underlying library without recompiling |
13 |
> > anything. |
14 |
> |
15 |
> Instead of manipulating symlinks, I wrote a dedicated eselect module |
16 |
> for BLAS: |
17 |
> |
18 |
> https://github.com/cdluminate/my-overlay/blob/master/app-eselect/eselect-blas/files/blas.eselect-0.2 |
19 |
> |
20 |
> This implementation will generate a corresponding ld.so.conf file |
21 |
> on switching and refresh ld.so cache. |
22 |
> |
23 |
> advantages: |
24 |
> |
25 |
> 1. not longer manipulates symlinks under package manager directory, |
26 |
> see https://bugs.gentoo.org/531842 and https://bugs.gentoo.org/632624 |
27 |
> |
28 |
> 2. we don't have to think about static lib and header switching like |
29 |
> Debian does. |
30 |
> |
31 |
> > * When a program is linked against a specific implementation, e.g. |
32 |
> > libmkl_rt.so, the solution doesn't break anything. |
33 |
> |
34 |
> This still holds with the new solution. |
35 |
> |
36 |
> > Solution |
37 |
> > -------- |
38 |
> > |
39 |
> > Similar to Debian's update-alternatives mechanism, Gentoo's eselect |
40 |
> > is good at dealing with drop-in replacements as well. My preliminary |
41 |
> |
42 |
> The redesigned solution totally diverted from Debian's solution. |
43 |
> |
44 |
> * sci-libs/lapack provides standard API and ABI for BLAS/CBLAS/LAPACK |
45 |
> and LAPACKE. It provides a default set of libblas.so, libcblas.so, |
46 |
> and liblapack.so . Reverse dependencies linked against the three |
47 |
> libraries (reference blas) will take advantage of the runtime |
48 |
> switching mechanism through USE="virtual-blas virtual-lapack". |
49 |
> Reverse dependencies linked to specific implementations such as |
50 |
> libopenblas.so won't be affected at all. |
51 |
> |
52 |
> * every non-standard BLAS/LAPACK implementations could be registered |
53 |
> as alternatives via USE="virtual-blas virtual-lapack". Once the |
54 |
> virtual-* flags are toggled, the ebuild file will build some |
55 |
> extra shared objects with correct SONAME. |
56 |
> |
57 |
> For example: |
58 |
> |
59 |
> /usr/lib64/libblis.so.2 (SONAME=libblis.so.2, general purpose) |
60 |
> /usr/lib64/blas/blis/libblas.so.3 (USE="virtual-blas", |
61 |
> SONAME=libblas.so.3) |
62 |
> /usr/lib64/blas/blis/libcblas.so.3 (USE="virtual-blas", |
63 |
> SONAME=libcblas.so.3) |
64 |
> |
65 |
> * Reverse dependencies of BLAS/LAPACK could optionally provide the |
66 |
> "virtual-blas virtual-lapack" USE flags. |
67 |
> |
68 |
> if use virtual-*: |
69 |
> link against reference blas/lapack |
70 |
> else: |
71 |
> link against whatever the ebuild maintainer like and get rid |
72 |
> of the switching mechanism |
73 |
> |
74 |
> > Proposed Changes |
75 |
> > ---------------- |
76 |
> > |
77 |
> > 1. Deprecate sci-libs/{blas,cblas,lapack,lapacke}-reference from gentoo |
78 |
> > main repo. They use exactly the same source tarball. It's not quite |
79 |
> > helpful to package these components in a fine-grained manner. A |
80 |
> > single |
81 |
> > sci-libs/lapack package is enough. |
82 |
> |
83 |
> sci-libs/{blas,cblas,lapack,lapacke}::gentoo should be deprecated. They |
84 |
> are based on exactly the same source tarball, and maintaining 4 ebuild |
85 |
> files for a single tarball is not a good choice IHMO. Those old ebuild |
86 |
> files seems to leverage the flexibility of upstream build system |
87 |
> because it enables one to, for example, skip the reference blas build |
88 |
> and use an existing optimized BLAS impelementation and hence introduce |
89 |
> flexibility. That flexibility is hard to maintain and is not necessary |
90 |
> anymore with the new runtime switching mechanism. |
91 |
> |
92 |
> That's why I propose to merge the 4 ebuild into a single one: |
93 |
> sci-libs/lapack. We don't need to add the "reference" postfix |
94 |
> because no upstream will loot the name "lapack". When talking |
95 |
> about "lapack" it's always the reference implementation. |
96 |
|
97 |
What's the real gain here, and how does it compare to loss of |
98 |
flexibility of being able to build only what the package in question |
99 |
needs? |
100 |
|
101 |
|
102 |
-- |
103 |
Best regards, |
104 |
Michał Górny |