FS#59046 - [openblas] undefined reference to `cblas_dnrm2'

Attached to Project: Community Packages
Opened by freyr (freyr) - Sunday, 17 June 2018, 18:58 GMT
Last edited by Jelle van der Waa (jelly) - Sunday, 03 September 2023, 09:15 GMT
Task Type Bug Report
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

Description:

openblas package includes cblas implementation as well, so a vanilla libopenblas library
also contains cblas_* symbols. In the current openblas package libopenblas does not include
any of cblas_* symbols, so my simple test program (which is expected to be linked against -lopenblas)
fails to compile, emitting "undefined reference to `cblas_dnrm2'".

This package from aur works perfectly fine for me, libopenblas.so contains cblas_* symbols as well:

https://aur.archlinux.org/packages/openblas-lapack/
   test.c (0.2 KiB)
This task depends upon

Closed by  Jelle van der Waa (jelly)
Sunday, 03 September 2023, 09:15 GMT
Reason for closing:  No response
Comment by Felix Yan (felixonmars) - Monday, 18 June 2018, 18:43 GMT
I would like to avoid duplicate the other parts. Does it work if you patch related software to link against cblas as well?
Comment by freyr (freyr) - Tuesday, 19 June 2018, 21:45 GMT
Well, yeah, but I also need to link against lapacke then, which is also missing. Is such package separation so crucial, couldn't openblas package just provide its own implementations of cblas and lapack/lapacke (as links) as it is intended to do (or just to have netlib blas as the only libblas)? Because software linking against openblas could possibly require lapacke and cblas as well (openblas implementations). I'm not sure that ATLAS/netlib/openblas implementations are identical, so i'm not sure if it does make sense to mix them that way anyway.
Comment by A H (ahaldane) - Thursday, 25 October 2018, 23:43 GMT
I think it's really important to keep the cblas symbols in the openblas .so file.

If I understand, with this setup if you want to link cblas functions you have to do both gcc -lopenblas and -lcblas. This contradicts the openblas documentation which says you only need to do -lopenblas to get the cblas functions.

This breaks a lot of project's build code. For instance, this has broken numpy builds which expect to only have to link `-openblas` to get access the the cblas functions. It breaks the openblas examples too.
Comment by Teodor Nikolov (teonnik) - Thursday, 13 June 2019, 13:32 GMT
I agree with ahaldane and freyr, it is very important that the cblas inrefaces are part of the openblas package. The library is hardly usable from C/C++ codes otherwise.
Comment by Michaël Defferrard (mdeff) - Friday, 03 April 2020, 03:13 GMT
I agree with freyr, ahaldane, and teonnik. I tried to compile a compelling argumentation in https://bugs.archlinux.org/task/66092.
Comment by Andrew Jong (ajong) - Wednesday, 08 April 2020, 23:28 GMT
I agree that the missing cblas symbols are breaking build code. I'm trying to install the Caffe deep learning framework with OpenBLAS, but it complains that it's missing cblas_* symbols. ATLAS is not a suitable alternative because it takes much too long to tune and install.
Comment by Felix Yan (felixonmars) - Sunday, 04 June 2023, 20:24 GMT
Should have been fixed in 0.3.23-2. Please let me know if it works as expected.
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...