Closed rgommers closed 4 years ago
You have to install openblas
package which gives you the library without the version and the headers.
You can also install blas-devel
which installs openblas
for the openblas variant and the corresponding package for others as well.
Thanks @isuruf. Somehow that didn't cross my mind - makes perfect sense. Sorry for the noise.
It's not (or no longer) possible to build NumPy directly against OpenBLAS in a conda-forge based dev environment.
This is a
numpy.distutils
/conda-forge
incompatibility. The conda-forge packaging seems fine in principle, and OpenBLAS is installed aslibopenblas.0.dylib
. That lib isn’t picked up by thenumpy.distutils
detection code though; when I create a symlink right next to it with.0
removed then it does get picked up, and NumPy builds and tests fine. The normal convention is to have both a “base name” for the shared library, and a versioned library. This is the case for libblas for example:However it’s not for
libopenblas
, likely because everything in the conda-forge channel has to link to the mutexblas
package instead, and letting users build directly against OpenBLAS wasn't considered.There's two possible fixes:
libopenblas.dylib
numpy.distutils
Given that (2) won't fix the issue for users/packages that don't use
numpy.distutils
, I'd prefer (1) I think. Also looking at my/usr/lib
and/usr/local/lib
I cannot see a single library that only provides a versioned.X.dylib
library - so arguably this is an OpenBLAS packaging bug.Also, I checked BLIS for comparison, which does have the base name: