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.
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.
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
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.
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