On 2014-01-22 09:04, Sébastien Fabbro wrote:
On Tue, Jan 21, 2014 at 11:26 AM, Reinis Danne <[email protected]>
wrote:
How the eselect module creation could work? Something like this?
~# eselect module create blas
~# eselect blas add atlas importance src dest [src dest [..]]
...
~# eselect blas remove atlas
~# eselect delete blas
That is the idea. Last one should be "eselect module delete blas".
* given the number of bugs, we should keep the linking to the
reference
names libraries, so we could eselect providers without
re-compiling all
reverse dependencies. We could do this in the open sourced
providers by
changing the soname of the libraries we compile, and in the
binary ones
(mkl,amcl...) with a link script generated library.
Yes, this is ok and AFAICT it is like that now in the overlay.
It is not. Let's take blas for example. Install openblas and
blas-reference, then eselect blas reference. Then install
lapack-reference, then remove blas-reference. You will have to
re-install lapack-reference, because of a missing reference to
librefblas.so. If openblas had the libblas.so soname and link, you
would not have to. I'm actually not sure whether it is a side effect
of our as-needed policy.
Just to make sure the message is clear, I use openblas:
readelf -d /usr//lib64/libreflapack.so
Dynamic section at offset 0x4f9e08 contains 26 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library:
[libopenblas.so.0]
0x0000000000000001 (NEEDED) Shared library:
[libgfortran.so.3]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000e (SONAME) Library soname:
[libreflapack.so]
So the soname is embedded in the shared object and the linker will look
for it
at runtime. Remove openblas and my reflapack is broken in spite of the
fact that
I have 2 other blas on the system.
