There appear to be errors in the return types for some single precision BLAS functions in the Apple -framework accelerate library. These errors exist for both intel and arm64 hardware. Here is a small fortran program that demonstrates these errors: 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 The correct output is: $ ifort -L${MKLROOT}/lib -Wl,-rpath,${MKLROOT}/lib -lmkl_intel_lp64 -lmkl_intel_thread -lmkl_core -liomp5 -lpthread 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 With the Apple -framework accelerate library, I get $ ifort -framework accelerate sblas.f90 && a.out sdot= .000 should be 7.000 sdsdot= .000 should be 7.000 snrm2= .000 should be 5.000 scnrm2= .000 should be 7.071 sasum= .000 should be 7.000 scasum= .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 The REAL results are incorrect, while the single precision COMPLEX results are alright. Some experimentation reveals that the problem is that the function return values are REAL(8) rather than the correct REAL. If I try gfortran instead of ifort, I get: $ gfortran -framework accelerate sblas.f90 && 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 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0  0x10af498be #1  0x10af48a9d #2  0x7fff207ced7c #3  0x7fff2105dfc8 #4  0x10af37bc1 #5  0x10af37d7e Segmentation fault: 11 Here, not even the single precision COMPLEX results are returned correctly. Presumably, the accelerate library passes its regression tests. This implies that the regression tests have the incorrect return types declared for these functions. Thus to correct this error, both the library and its regression tests must be corrected together.

I am having problems installing the Curses perl library from CPAN. I have been installing this on various versions of MacOS since 2001 with little or no problems. Now I'm trying to install it on Monterey (12.5), and I'm not making much progress. The main problem seems to be that curses.h is not found during the compile step and -lcurses is not found during the load step. On my 10.14.6 system where everything works, the header file is in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/curses.h and the loader stub file is in /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib/libcurses.tbd That stub file points to /usr/lib/libncurses.5.4.dylib, which I can verify does exist. However, on my 12.5 system, the header and the stub files exist, but the actual *dylib file is not there. I originally had these problems when I had only the command line tools installed on the 12.5 system. I have subsequently downloaded the full Xcode (about 30GB!!!), thinking that might fill in the missing pieces, but I still get the same errors. I presume that I have done something wrong during the command line tools install or during the full Xcode install, or maybe I need some environment variables to be set appropriately. Or maybe I need to somehow tell Xcode to download and install that *dylib file? I have never had to debug this before, so I don't really know how the CPAN install process works, despite using it for 20 years. In the past, it has always just worked with minimal effort. Has anyone else had this problem and know the solution?