http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 http://bugzilla.opensuse.org/show_bug.cgi?id=1177260#c11 --- Comment #11 from Stefan Brüns <stefan.bruens@rwth-aachen.de> --- (In reply to Egbert Eich from comment #10)
(In reply to Stefan Brüns from comment #8)
Your changes to lapack looked fine. I've sent them on to Factory. I cannot accept your drop request for science/CBLAS, yet, as it is still the devel project for Factory. I've filed a separate drop request for that. The priorities of liblapack, libblas and libcblas from the netlib lapack are higher than for the ones from openblas. Thus, even if openblas is installed, it will not be picked up automatically. Do you prefer it this way?
While looking at this, I've noticed there are no update-alternatives for the lapack C interface. openblas does provide this as well, though. It should probably be added.
LapackE should be covered as well, yes. Though, the current update-alternatives setup is somewhat problematic IMHO - switching only some parts of the blas implementation does not make sense, and may even lead to strange bugs. I propose to replace the individual library symlinks with a directory symlink. For each variant, have one '/usr/lib(64)/blas-{netlib,openblas_X,...}/' directory which contains all the blas-related libraries. Then add a /usr/lib(64)/blas-default symlink (managed by ua) pointing to e.g. /usr/lib(64)/blas-openblas_serial/. /usr/lib(64)/blas-netlib would contain e.g. libblas.so.3,liblapack.so.3,etc as individual libraries (or appropriate symlinks), while /usr/lib(64)/blas-openblas_serial/ would contain libblas.so.3,liblapack.so.3,etc as symlinks all pointing to the libopenblas_serial.so file. The default would become visible by adding /usr/lib(64)/blas-default/ to /etc/ld.so.conf. This also makes it easy to override the blas implementation for an individual application, just add e.g. /usr/lib(64)/blas-openblas_pthreads/ to LD_LIBRARY_PATH. -- You are receiving this mail because: You are on the CC list for the bug.