On Mon, 23 Sep 2013 14:20:03 +0200
Kevin Kofler <kevin.kofler(a)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(a)fedoraproject.org