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: | Well, I'm also a Fedora packager, and I think that, as long as we want to | support multiple implementations of BLAS/LAPACK, the system which has been | used for ATLAS in Fedora until now (i.e. the implementations all have the | same sonames, and ld.so.conf.d is used to tell the linker to pick a | specific implementation at runtime) is much better. For us packagers, it | means that we only have to BuildRequire lapack-devel and not have to worry | about what the most optimized implementation available for the given | (possibly secondary) architecture is. For the end users, it means that | they can install the most optimized implementation we provide for their | CPU, or even build their own (tuned for the exact properties of their | machine), without having to recompile all the packages using BLAS and/or | LAPACK. | | In addition, as I have already written on the Fedora devel list, shipping | multiple implementations in a way where different packages can (easily) | link a different implementation (technically, this was also possible with | the old solution by abusing rpath, but then the rpath is your problem, | rpaths are evil) is a surefire recipe for symbol conflicts. 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. (What happens if the linker loads the reference | libblas.so.3 first and resolves the BLAS symbols against that, then loads | libopenblas.so.* and tries to resolve the LAPACK symbols against that?) So | the only realistic solution I see for Fedora if libopenblas.so is what | we're going to be stuck with is to build everything against OpenBLAS and | support only OpenBLAS. Of course, you as OpenBLAS maintainers probably | like this solution. ;-) But I'm not convinced that this is realistically | doable in Fedora due to the politics involved. We haven't even managed to | prevent MySQL-Community and Apache OpenOffice from being (re)introduced | next to the default MariaDB and LibreOffice. So the symbol conflicts would | likely become a serious practical problem. | | 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! To properly | support parallel LAPACK/BLAS, you have to build separate serial and | parallel versions of ALL the libraries that use LAPACK and/or BLAS, even | indirectly! That would probably be many more packages than you expect. Kevin Kofler -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
