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