[HEADSUP] Atlas changed libraries

[Kevin Kofler]

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