# How many BLAS libraries have this error? **URL:** \ **Category:** Uncategorized\ **Created:** [October 4, 2022, 8:33pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454 "2022-10-04T20:33:25Z")\ **Posts on this page:** 18\ **Page:** 2
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [October 18, 2022, 2:56pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/22 "2022-10-18T14:56:07Z")
> [@drikosev](#): > > When I run on macOS Mojave this “gfc -lblas sblas.f90 && ./a.out” I also saw a segfault. > With a custom installation of LAPACK (3.9.0) I’ve to link with the (confusing) “-lrefblas” and then I see: 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. ---
**Author:** ![drikosev](https://avatars.discourse-cdn.com/v4/letter/d/e47c2d/32.png) [@drikosev](https://fortran-lang.discourse.group/u/drikosev)\ **Post date:** [October 18, 2022, 3:19pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/23 "2022-10-18T15:19:28Z")
> [@RonShepard](#): > > 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? 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](https://fossies.org/linux/misc/lapack-3.9.0.tar.gz) The installation instructions for OSX 10.9, up to macOS Mojave, are here: > **[GitHub - drikosev/pc: It contains a few Bash Scripts, which can help one...](https://github.com/drikosev/pc)** > > It contains a few Bash Scripts, which can help one install open source developer tools on OS X. - GitHub - drikosev/pc: It contains a few Bash Scripts, which can help one install open source develo... 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 ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [October 18, 2022, 6:12pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/24 "2022-10-18T18:12:19Z")
> [@drikosev](#): > > 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](https://fossies.org/linux/misc/lapack-3.9.0.tar.gz) 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. ---
**Author:** ![drikosev](https://avatars.discourse-cdn.com/v4/letter/d/e47c2d/32.png) [@drikosev](https://fortran-lang.discourse.group/u/drikosev)\ **Post date:** [October 18, 2022, 11:25pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/25 "2022-10-18T23:25:50Z")
> [@RonShepard](#): > > That link does not work. Hello, File gone - probably newer version of requested archive available: [https://fossies.org/linux/misc/lapack-3.10.1.tar.gz/](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](http://distfiles.macports.org/lapack/lapack-3.9.0.tar.gz) or one can download it from [LAPACK — Linear Algebra PACKage](http://www.netlib.org/lapack/) 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 ---
**Author:** ![meow464](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/meow464/32/1987_2.png) [@meow464](https://fortran-lang.discourse.group/u/meow464)\ **Post date:** [October 19, 2022, 10:09pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/26 "2022-10-19T22:09:34Z")
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. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [October 24, 2022, 9:50pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/27 "2022-10-24T21:50:19Z")
Here is an update using OpenBLAS installed with Homebrew on MacOS: ```auto $ 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. ---
**Author:** ![waveman](https://avatars.discourse-cdn.com/v4/letter/w/e95f7d/32.png) [@waveman](https://fortran-lang.discourse.group/u/waveman)\ **Post date:** [August 25, 2023, 7:19am UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/28 "2023-08-25T07:19:52Z")
Just curious why this wasn’t mentioned: f2c-converted cblas was deprecated at some point. I have read multiple threads advising against it. AFAIK, all cblas worth their salt are not f2c-converted. Has anyone tried to contact Apple? ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [August 25, 2023, 5:15pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/29 "2023-08-25T17:15:51Z")
This problem traces back to f2c source code conversions and to the K&R C convention of promoting float to double. However, it persists beyond the f2c converted code because the error had established itself at that point, and in order for new tests to pass old benchmarks, the conversion error had to be propagated. The C code for a typical blas library has preprocessor macros that allow the installation to select which convention to use, so to at least a substantial fraction of C programmers, this type conversion has become the “correct” behavior, despite the fact that the reference fortran code never had this conversion. I did submit the error to Apple, and they did respond that they were working on the code (and presumably the associated tests). I have not installed a recent Xcode or the command line tools (which is where the -framework accelerate libraries live), so I do not know if it has been corrected since the original posts in this thread. Has anyone here compiled and run these tests with recent MacOS or Xcode software versions? ---
**Author:** ![ivanpribec](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/ivanpribec/32/3290_2.png) [@ivanpribec](https://fortran-lang.discourse.group/u/ivanpribec)\ **Post date:** [August 31, 2023, 2:44pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/30 "2023-08-31T14:44:57Z")
The `snrm2` bug hits again: [rust - snrm2 calculation instability for single-precision floats on Accelerate - Stack Overflow](https://stackoverflow.com/questions/76947368/snrm2-calculation-instability-for-single-precision-floats-on-accelerate) The answer is worth a +200 reputation bounty if you can answer in the next hour. ---
**Author:** ![dasergatskov](https://avatars.discourse-cdn.com/v4/letter/d/7feea3/32.png) [@dasergatskov](https://fortran-lang.discourse.group/u/dasergatskov)\ **Post date:** [January 21, 2025, 9:33pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/31 "2025-01-21T21:33:14Z")
> [@RonShepard](#): > > Has anyone here compiled and run these tests with recent MacOS or Xcode software versions? Just to keep the thread alive. The problem is still there (using `flexiblas` shim library to allow run-time switching between BLAS libraries): ```auto % xcodebuild -version Xcode 16.2 Build version 16C5032a % cat t2.f90 program sblas ! test some single-precision blas results. implicit none real :: x(2)=[3.,4.], y(2)=[1.,1.] complex :: w(2)=[(4.,3.),(3.,4.)], z(2)=[(5.,6.),(7.,8.)] real, external :: sdot, sdsdot, snrm2, scnrm2, sasum, scasum complex, external :: cdotu, cdotc character(*), parameter :: cfmt='(*(g0.4,1x))' write(*,cfmt) 'sdot=', sdot(2,x,1,y,1), 'should be 7.000' write(*,cfmt) 'sdsdot=', sdsdot(2,0.0,x,1,y,1), 'should be 7.000' write(*,cfmt) 'snrm2=', snrm2(2,x,1), 'should be 5.000' write(*,cfmt) 'scnrm2=', scnrm2(2,w,1), 'should be 7.071' write(*,cfmt) 'sasum=', sasum(2,x,1), 'should be 7.000' write(*,cfmt) 'scasum=', scasum(2,w,1), 'should be 14.00' write(*,cfmt) 'cdotu=', cdotu(2,w,1,z,1), 'should be -9.000 91.00' write(*,cfmt) 'cdotc=', cdotc(2,w,1,z,1), 'should be 91.00 5.000' end program sblas ``` ```auto % gfortran t2.f90 -lflexiblas -L/opt/homebrew/lib % flexiblas list System-wide: System-wide (config directory): APPLE library = libflexiblas_apple.dylib comment = NETLIB library = libflexiblas_netlib.dylib comment = OPENBLASOPENMP library = libflexiblas_openblasopenmp.dylib ... % FLEXIBLAS=NETLIB ./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 % FLEXIBLAS=OPENBLASOPENMP ./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 % FLEXIBLAS=APPLE ./a.out sdot= 0.000 should be 7.000 sdsdot= 0.000 should be 7.000 snrm2= 0.000 should be 5.000 scnrm2= 0.000 should be 7.071 sasum= 0.000 should be 7.000 scasum= 0.000 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 ``` ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [January 21, 2025, 10:45pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/32 "2025-01-21T22:45:13Z")
> [@dasergatskov](#): > > The problem is still there […] Thanks for the update. I’m still an OS version behind, so I have not tested this lately. ---
**Author:** ![FedericoPerini](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/federicoperini/32/1750_2.png) [@FedericoPerini](https://fortran-lang.discourse.group/u/FedericoPerini)\ **Post date:** [January 22, 2025, 7:44am UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/33 "2025-01-22T07:44:14Z")
FYI tested on macOS Sonoma 14.6.1 + gfortran 14.2.0 and the `stdlib` interface: ```auto program sblas use stdlib_linalg_blas ! test some single-precision blas results. implicit none(type,external) real :: x(2)=[3.,4.], y(2)=[1.,1.] complex :: w(2)=[(4.,3.),(3.,4.)], z(2)=[(5.,6.),(7.,8.)] character(*), parameter :: cfmt='(*(g0.4,1x))' write(*,cfmt) 'sdot=', dot(2,x,1,y,1), 'should be 7.000' write(*,cfmt) 'sdsdot=', stdlib_sdsdot(2,0.0,x,1,y,1), 'should be 7.000' write(*,cfmt) 'snrm2=', nrm2(2,x,1), 'should be 5.000' write(*,cfmt) 'scnrm2=', nrm2(2,w,1), 'should be 7.071' write(*,cfmt) 'sasum=', asum(2,x,1), 'should be 7.000' write(*,cfmt) 'scasum=', asum(2,w,1), 'should be 14.00' write(*,cfmt) 'cdotu=', dotu(2,w,1,z,1), 'should be -9.000 91.00' write(*,cfmt) 'cdotc=', dotc(2,w,1,z,1), 'should be 91.00 5.000' end program sblas ``` - Using our internal implementation everything works OK: ```toml [dependencies] stdlib ="*" ``` ```sh fpm run 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 ``` - With the Accelerate backend, it returns wrong results and crashes on `dotu`: ```toml [dependencies] stdlib = { git="https://github.com/fortran-lang/stdlib", branch="stdlib-fpm", preprocess.cpp.macros=["STDLIB_EXTERNAL_BLAS", "STDLIB_EXTERNAL_LAPACK"] } ``` ```sh fpm run --flag " -framework Accelerate" sdot= 0.000 should be 7.000 sdsdot= 7.000 should be 7.000 snrm2= 0.000 should be 5.000 scnrm2= 0.000 should be 7.071 sasum= 0.000 should be 7.000 scasum= 0.000 should be 14.00 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x1050bad2f #1 0x1050b9d83 #2 0x198e22583 #3 0x104a71d8b #4 0x104a71e0f Execution for object " sblas_test " returned exit code 11 *cmd_run*:stopping due to failed executions STOP 11 ``` ---
**Author:** ![foxtran](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/foxtran/32/6459_2.png) [@foxtran](https://fortran-lang.discourse.group/u/foxtran)\ **Post date:** [November 26, 2025, 3:25pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/34 "2025-11-26T15:25:46Z")
After some debugging, I’ve found that the problem is actually gone since MacOS 13.3. But the solution is a bit tricky. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [November 26, 2025, 5:47pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/35 "2025-11-26T17:47:02Z")
> [@foxtran](#): > > After some debugging, I’ve found that the problem is actually gone since MacOS 13.3. If you mean the Apple accelerate library, the error has persisted up through MacOS 15.7.2. I have not yet upgraded to MacOS 26 on any of my machines. This was reported to Apple in October 2022. I received a response a few weeks later saying that the error would be fixed in a future MacOS and Xcode release. So far, that has not happened. ---
**Author:** ![foxtran](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/foxtran/32/6459_2.png) [@foxtran](https://fortran-lang.discourse.group/u/foxtran)\ **Post date:** [November 26, 2025, 7:27pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/36 "2025-11-26T19:27:18Z")
Unfortunately, I’m using MacOS 13.7. And I found how to avoid this bug on my machine. ---
**Author:** ![mecej4](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/mecej4/32/855_2.png) [@mecej4](https://fortran-lang.discourse.group/u/mecej4)\ **Post date:** [November 27, 2025, 11:45am UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/37 "2025-11-27T11:45:55Z")
There are [several reports](https://github.com/scipy/scipy/wiki/Dropping-support-for-Accelerate/f17f574bc17ee688c3a2b6395d262e71fff4c77c) of bugs in Apple’s accelerate framework. They suggest that users be aware of such issues and rely on alternative libraries that are more reliable. ---
**Author:** ![RonShepard](https://avatars.discourse-cdn.com/v4/letter/r/a3d4f5/32.png) [@RonShepard](https://fortran-lang.discourse.group/u/RonShepard)\ **Post date:** [November 27, 2025, 4:46pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/38 "2025-11-27T16:46:40Z")
> [@mecej4](#): > > They suggest that users be aware of such issues and rely on alternative libraries that are more reliable. That is one reason why public discussions like this one are important, so that users are aware of such problems. However, the solution to use another library also has consequences. I’m unaware of any BLAS library from any other source that runs as fast as the Apple accelerate library on Apple hardware (arm64 M1, M2, M3, M4). So the best solution remains for Apple to fix their bugs. This particular collection of bugs all seem to be relatively easy to fix. ---
**Author:** ![foxtran](https://yyz2.discourse-cdn.com/free1/user_avatar/fortran-lang.discourse.group/foxtran/32/6459_2.png) [@foxtran](https://fortran-lang.discourse.group/u/foxtran)\ **Post date:** [November 27, 2025, 8:32pm UTC](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454/39 "2025-11-27T20:32:48Z")
There is an interface to BLAS and LAPACK routines: > **[GitHub - foxtran/BLAS77Interface: Fortran 90 modules and wrappers for BLAS & LAPACK...](https://github.com/foxtran/BLAS77Interface)** > > Fortran 90 modules and wrappers for BLAS & LAPACK routines you can go directly to examples, configure with: cmake -Bbuild -DBLA\_VENDOR=Apple and build and run couple of examples which I took from this thread. I patched examples by removing external routines, since now all interfaces are available in module blas77. After this, they works properly with my very old Intel Mac with 13.7.8 Ventura. Unfortunately, I did not dump every routine from LAPACK, but it is not a problem to fix it: I just need more time and fix an issue with external keyword for bind(C) routines. Actually, what is a big problem with Fortran, that GFortran (and other Fortran compilers) still uses old ABI/API of framework Accelerate. Once one switches to proper ABI/API, everything works. [Previous page](https://fortran-lang.discourse.group/t/how-many-blas-libraries-have-this-error/4454.md?page=1)