[HEADSUP] Atlas changed libraries

[Susi Lehtola]

On Mon, 23 Sep 2013 14:20:03 +0200
Kevin Kofler <kevin.kofler at chello.at> wrote:

> Susi Lehtola wrote:
> > ... huh?
> > 
> > ATLAS, OpenBLAS and (netlib reference) LAPACK are all mutually
> > incompatible packages.
> > 
> > If you linked with -L%{_libdir}/atlas -llapack -lf77blas -latlas,
> > what you ended up with is the ATLAS version (*not* the same as
> > netlib lapack!) of LAPACK and the ATLAS blas library, which reside
> > in %{_libdir}/atlas/liblapack.so
> >  %{_libdir}/atlas/libf77blas.so
> >  %{_libdir}/atlas/libatlas.so
> > Alternatively, instead of -lf77blas you could use -lptf77blas which
> > is the threaded version. Now the packaging is just saner, so you
> > only need to link -latlas or -lsatlas to get all symbols.
> > 
> > If you linked with -lopenblas (or -lopenblaso or -lopenblasp), you
> > get the OpenBLAS lapack and blas libraries.
> > 
> > If you linked with -llapack -lblas, you get the reference netlib
> > lapack and blas libraries.
> 
> The way things worked in the past, if you built your programs against 
> lapack-devel and/or blas-devel, they would pick up the ATLAS
> libraries if available at runtime (due to the ld.so.conf.d
> overrides), and the reference libraries otherwise. You only had to BR
> atlas-devel if you tried to use stuff such as cblas which we weren't
> packaging separately.

Yes, maybe when you use LAPACK since ATLAS used to piggyback the same
name.

> Now with the differently-named ATLAS libraries, only programs built
> against atlas-devel will pick up ATLAS at runtime.

... and this is a problem why?

There's a big bunch of BLAS/LAPACK libraries out there, ACML, MKL,
ATLAS, GotoBLAS, OpenBLAS, just to name a few.
 
> As those libraries all export the same symbols, this also sounds like
> a surefire recipe for symbol conflicts to me! Imagine an app built
> against OpenBLAS using a library A linked against ATLAS and a library
> B linked against reference BLAS/LAPACK. You get 3 implementations of
> some symbols, who knows which will get picked by the linker, and you
> could end up with some mix of symbols which doesn't work at all.

Yes, this might be a problem if you use libraries that also link to
some blas library. But these cases can be handled as in GSL: even
though the GSL library has ties to CBLAS, you can pick the CBLAS
library you want to use at compile time.

> I think we need to enforce ONE implementation of BLAS and LAPACK and
> ship that as libblas.so and liblapack.so (even if those are just
> symlinks or linker scripts pointing to libopenblas.so or libsatlas.so
> or whatever).

OpenBLAS, ATLAS, ACML and MKL only ship one monolitchic library, so this
is not really an option.
-- 
Susi Lehtola
Fedora Project Contributor
jussilehtola at fedoraproject.org