How many BLAS libraries have this error?

#22

What exactly are these libraries? Is -lblas part of the standard OS development system, or is it something that you installed separately? If a separate install, is the code written in C or fortran?

Is -lrefblas compiled from the fortran code from netlib?

So far, it seems that all of the various libraries that have these single-precision errors are written in C, not fortran, and the return type errors trace back to the f2c compiler and to the K&R C convention of promoting float to double.

1 Like
#23

Dear Ron Shepard,

To my understanding the code is written in Fortran. The installed library
has passed all the recommended tests, as set by LAPACK mainainers:
https://fossies.org/linux/misc/lapack-3.9.0.tar.gz

The installation instructions for OSX 10.9, up to macOS Mojave, are here:

I see the same results on Cygwin as well (with a newer gfortran-10).

To create the static libraries, one has to download the latest tarball:
pc-rules-2021-03-05.tar.bz2

#24

That link does not work. If it is fortran code, could you please just look to see hows sdot(), snrm2(), etc. are declared? It would be surprising to see correct declarations in both the test program and the library that results in either incorrect results or in the segfault.

#25

Hello,

File gone - probably newer version of requested archive available:
https://fossies.org/linux/misc/lapack-3.10.1.tar.gz/

In alternative, one can find the exact version in macports:
http://distfiles.macports.org/lapack/lapack-3.9.0.tar.gz

or one can download it from LAPACK — Linear Algebra PACKage

Once this exact version is in folder Downloads the outdated
PC script will not attempt to download it again. To see the build
instructions one can type:

./port details lapack NODEPS=X

If you have GNU C, FORTRAN in /usr/local/bin/ this might work:

./port archive lapack NODEPS=X

With good luck one may find a package at /tmp/archives

#26

I didn’t come across this bug specifically but I did notice F2C LAPACK and Accelerate LAPACK are stuck on API 3.2.1. An interesting coincidence. I suspect reporting to Apple may not yield fruitful results, IIRC Numpy/Scipy already tried that.

1 Like
#27

Here is an update using OpenBLAS installed with Homebrew on MacOS:

$ uname -m
arm64
$ gfortran -L/opt/homebrew/opt/openblas/lib -lblas sblas.F90 && a.out
sdot= 7.000 should be 7.000
sdsdot= 7.000 should be 7.000
snrm2= 5.000 should be 5.000
scnrm2= 7.071 should be 7.071
sasum= 7.000 should be 7.000
scasum= 14.00 should be 14.00
cdotu= -9.000 91.00 should be -9.000 91.00
cdotc= 91.00 5.000 should be 91.00 5.000

So all is good with a recent OpenBLAS install.

1 Like