[HEADSUP] Atlas changed libraries

[Kevin Kofler]

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.

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

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.

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).

        Kevin Kofler