FS#66092 - [openblas] provide cblas, lapack, lapacke

Attached to Project: Community Packages
Opened by Michaël Defferrard (mdeff) - Friday, 03 April 2020, 03:11 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:07 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

Currently, community/openblas (unlike aur/openblas-lapack) doesn't build and provide OpenBLAS's optimized lapack neither their C bindings (cblas and lapacke).

However, building and providing lapack and the C bindings has multiple advantages.
1. Providing the C bindings would solve bugs raised in Arch:
* https://bugs.archlinux.org/task/59046
* https://bugs.archlinux.org/task/63054
2. OpenBLAS optimized some LAPACK routines that would become available by providing lapack (and lapacke). See also https://bugs.archlinux.org/task/62558.
3. It's both the default upstream configuration and what mainstream users expect and test (as it's what they do when they vendor OpenBLAS in pip wheels and conda packages).
* upstream OpenBLAS (https://github.com/xianyi/OpenBLAS/blob/develop/Makefile.rule)
* NO_CBLAS=1, NO_LAPACK=1, NO_LAPACKE=1 are all commented
* Julia: https://github.com/JuliaLang/julia/blob/master/deps/blas.mk
* (BTW, it should remove the need for our julia-system-cblas patch to community/julia)
* NumPy: https://github.com/numpy/numpy/blob/master/tools/openblas_support.py
4. Clearer for users: they either have BLAS and LAPACK from Netlib, or BLAS and LAPACK from OpenBLAS. No mix. Currently when a user installs openblas, they only get blas, while cblas, lapack, and lapacke are provided by extra/lapack (from the Netlib reference implementation).
5. Building and shipping packages in their entirety goes with the Arch principle of simplicity.

For these reasons, I hope community/openblas can build and provide cblas, lapack, lapacke (and aur/openblas-lapack retired). I can't think of any downsides, neither did I found any while researching the issue nor while using aur/openblas-lapack for years. Thanks for your work and considerations!
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:07 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/openblas/issues/3
Comment by Marcell Meszaros (MarsSeed) - Sunday, 27 February 2022, 10:53 GMT
  • Field changed: Percent Complete (100% → 0%)
I suggest it's reasonable to close stub-like  FS#62558  and reopen this task as it defines the request, the rationale and the problems clearly. Also I'd elevate severity because openblas without its built-in cblas/lapack replacements breaks a lot of downstream software.
Comment by LaserEyess (LaserEyess) - Tuesday, 28 March 2023, 22:09 GMT
I just ran into this myself. I know "+1"s usually aren't helpful in bugs, but on top of everything mentioned here I'd like to point out that numpy lists openblas as an optdepend "for faster linear algebra", but that's not true because there's no cblas or lapacke! That could be considered a numpy packaging bug but in any other distro it *would* be true because openblas wouldn't turn off these default features.
Comment by Felix Yan (felixonmars) - Sunday, 04 June 2023, 20:24 GMT
Implemented in 0.3.23-2. Please let me know if it works as expected.
Comment by Antonio Rojas (arojas) - Sunday, 04 June 2023, 22:52 GMT
The 64-bit integer version seems to be quite broken. I'm getting lots of segfaults in julia's test suite.

#0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
#1 0x00007fe23b9d82d3 in __pthread_kill_internal (signo=11, threadid=<optimized out>) at pthread_kill.c:78
#2 0x00007fe23b988a08 in __GI_raise (sig=11) at ../sysdeps/posix/raise.c:26
#3 <signal handler called>
#4 0x00007fe21fc4b6f7 in scopy_k_ZEN () from /usr/bin/../lib/julia/../libopenblas64_.so
#5 0x00007fe21ff062fd in slarre_ () from /usr/bin/../lib/julia/../libopenblas64_.so
#6 0x00007fe21fe656b9 in sstemr_ () from /usr/bin/../lib/julia/../libopenblas64_.so
#7 0x00007fe21fe06bdf in sstegr_ () from /usr/bin/../lib/julia/../libopenblas64_.so
Comment by Felix Yan (felixonmars) - Sunday, 04 June 2023, 23:04 GMT
I saw lots of segfaults in the tests of openblas too, and opened https://github.com/xianyi/OpenBLAS/issues/4072 for this. So turns out it's not only a test problem :(
Comment by Felix Yan (felixonmars) - Monday, 05 June 2023, 08:59 GMT
openblas 0.3.23-3 should have addressed the 64-bit integer version problems.
Comment by Christian Holme (Nordwin) - Thursday, 15 June 2023, 14:18 GMT
Thank you for providing openblas/cblas/lapack(e) outside of the AUR.

I am just confused about two things in the new packages:
1) Do you know why the headers and the libraries are split between "openblas" (headers) and "blas-openblas" (libs)?

2) And: Why are the headers in /usr/include/openblas instead of /usr/include (as was the case with the AUR package openblas-lapack. Also, ).

Especially 2) needed some less-than-beautiful workarounds when switiching my AUR-Packages (bart and bart-git) from openblas-lapack to the packages in the official repos.
Comment by Marcell Meszaros (MarsSeed) - Thursday, 15 June 2023, 14:50 GMT
See  FS#71927  which discusses the creation of the new split-package blas-openblas.

The placing of the header include files was not addressed there.
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...