Bug#598638: Question about a alternative impacting on an other

[Guillem Jover]

Hi!

[ Leaving most of the original mail intact for context. ]

On Thu, 2011-02-24 at 22:55:44 +0100, Sylvestre Ledru wrote:
> There is what I currently have. 
> I have two important linear algebra librairies which are managed by
> update-alternatives as primary:
> * libblas.so.3gf
> * liblapack.so.3gf
> 
> There are have various implementations. For now, we have a few of them:
> * refblas for libblas.
> * lapack for lapack.
> * atlas which provides both.
> 
> Switching to Atlas will update both blas and lapack alternatives.
> 
> This will work.
> 
> However, if manually, I update liblapack to Atlas:
> update-alternatives --config liblapack.so.3gf
> Obviously, it won't update the libblas.so.3gf.
> 
> In theory, this should not be a problem... However, lapack from Atlas
> uses some internal of libblas.so.
> IE, if the user has libblas.so configured as refblas.so and liblapack.so
> as Atlas. This will break (cf bug #598638).
> 
> Is there a way to have a kind of trigger in update-alternatives for this
> case ?

I don't think this is something that has to be fixed in
update-alternatives. To me this needs to be fixed in atlas itself.

If a library depends on symbols from another library, then it needs to
require so explicitly to the dynamic linker. Requiring the generic
library is not good nor correct enough (even if u-a would enforce some
kind of group links, as hooks is not the solution as they would need to
override any manual setting for example, or automatic priority).

So if liblapack-atlas.so links against libblas-atlas.so, and the
alternatives are set as liblapack.so (atlas) and libblas.so (blas),
an application linking against both generic versions might misbehave
as the linker might pick up symbols from either of the two libblas.so
libraries loaded (atlas, blas). The general solution to that is symbol
versioning. The other solution is to try to move the private symbols
into a common private library.

But here, it appears the solution might be even easier, libatlas3-base
already ships a /usr/lib/libatlas.so.3 library, which seems to contain
(after some random symbol checks) most if not all of the private ATL_
symbols. So it seems the correct fix would be to link both
libblas-atlas.so and liblapack-atlas.so against /usr/lib/libatlas.so.3
(instead of embedding the ATL_ private symbols themselves), this way
liblapack-atlas.so will not be making use of the private ATL_ symbols
from libblas-atlas.so, but directly from libatlas.so. (This should also
reduce the package size!)

Or did I miss something?

Thanks,
Guillem