[HEADSUP] Atlas changed libraries

Susi Lehtola jussilehtola at fedoraproject.org
Fri Sep 27 07:33:18 UTC 2013


On Thu, 26 Sep 2013 17:52:27 +0200
Kevin Kofler <kevin.kofler at chello.at> wrote:
> I wrote:
> > FYI, the author of netlib-java filed an issue with OpenBLAS for that:
> > https://github.com/xianyi/OpenBLAS/issues/296
> 
> I'm going to reproduce here the comment that I posted there:
> 
> | The situation I'm thinking of is an application linking one BLAS implementation, but the
> | libraries it uses linking one or more other one(s). In the best case,
> | you'd end up with an unexpected implementation (and so you're no better
> | off than before if you were relying on getting a specific one). In the
> | worst case, you end up with symbols from multiple implementations which
> | are incompatible enough to crash the program or cause it to fail with an
> | unresolved symbol.
> |
> | But yes, incompatibilities with parallelization are a problem. The default
> | implementation (shipped as libblas.so.3 and liblapack.so.3) can only
> | realistically be serial. But shipping the libraries with different names
> | doesn't help there, unless you're also renaming all the symbols. The
> | previous paragraph on symbol conflicts applies here too!

Multicore CPUs are nowadays the norm, and packages should really use
libraries that support this approach. Thus your argument is obsolete.
The parallel libraries are not interchangeable.

Currently your argument is rather theoretical. If you really feel
strongly about this, then prepare a packaging guideline along the lines
of the MPI guidelines, where there is a analogous situation with regard
to multiple implementations of the MPI standard.
-- 
Susi Lehtola
Fedora Project Contributor
jussilehtola at fedoraproject.org


More information about the devel mailing list