On Mon, 23 Sep 2013 14:20:03 +0200
Kevin Kofler <kevin.kofler@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxx
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
