Gentoo Archives: gentoo-science

From: Reinis Danne <rei4dan@×××××.com>
To: gentoo-science@l.g.o
Subject: Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates
Date: Tue, 21 Jan 2014 21:30:25
Message-Id: 20140121213017.GC13149@dhcppc1
In Reply to: Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates by "Sébastien Fabbro"
1 On Tue, Jan 21, 2014 at 12:04:43PM -0800, Sébastien Fabbro wrote:
2 > On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne <rei4dan@×××××.com> wrote:
3 >
4 > > > * given the number of bugs, we should keep the linking to the reference
5 > > > names libraries, so we could eselect providers without re-compiling all
6 > > > reverse dependencies. We could do this in the open sourced providers by
7 > > > changing the soname of the libraries we compile, and in the binary ones
8 > > > (mkl,amcl...) with a link script generated library.
9 > >
10 > > Yes, this is ok and AFAICT it is like that now in the overlay.
11 > >
12 > >
13 > It is not. Let's take blas for example. Install openblas and
14 > blas-reference, then eselect blas reference. Then install lapack-reference,
15 > then remove blas-reference. You will have to re-install lapack-reference,
16 > because of a missing reference to If openblas had the
17 > soname and link, you would not have to. I'm actually not sure
18 > whether it is a side effect of our as-needed policy.
19 >
20 > We need to change all blas ebuilds to make sure they have the same soname,
21 > and add to alternatives_for blas the libraries to link. For blas-reference,
22 > eigen, atlas and openblas, this is just a matter of a link flag. For acml
23 > and mkl, this is trickier, thus the gen_usr_ldscript from toolchain-funcs
24 > eclass idea. If the ldscript stuff is not much overhead, we could apply it
25 > to all.
26 >
27 > Sebastien
29 Ok, that is different issue. The question is whether we want,
30 e.g., eselect blas be build time only or also runtime setting.
32 If we use provider specific sonames, then the program will use
33 whatever provider was selected at build time even if different
34 provider is set afterwards. Thus it is build time only setting,
35 with the caveat that package has to be rebuilt if selected
36 provider is removed (preserved-libs should catch this).
38 ⬑ This is how it is now in the overlay.
40 If we provide generic sonames for alternatives (symlink or
41 ldscript), then program should use whichever provider is
42 currently selected. Thus it is runtime setting, with the caveat
43 that all packages can use only currently selected provider (user
44 has to keep track of selected provider).
46 Symlinks can be provided with the existing alternatives-2.eclass
47 if ebuilds choose to do so. Only change for generic pc file would
48 be not to point to selected provider's pc file, but to give
49 settings for generic libs (which is symlink to currently set). In
50 this case generic pc file generation should be added to eclass?
52 Is there any reason why it has not been used?
54 I don't know how often people actually do use specific providers
55 with different applications or how often they switch between
56 them?
58 As long as there are no programs with different preferred
59 providers, the generic libs would be ok. But if there are such
60 programs, then provider specific libs should be used. This could
61 already be done by picking provider specific pc file (and
62 optional USE-flags for providers in ebuilds).
64 AFAIK, benchmarking is the only use for generic libs (no need to
65 reinstall for every provider) and provider selection rarely
66 changes otherwise. Are there examples of opposite?
68 Could this be different for different alternatives (blas, cblas,
69 lapack, ...)?
72 Reinis


Subject Author
Re: [gentoo-science] [PATCH 00/10] alternatives-2.eclass updates "Sébastien Fabbro" <bicatali@g.o>