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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
