LAPACK on OSX 10.10

[richwolski]

Hi All,

Forgive me if this is a well known problem. I just had a Mac die and when I replaced it the new one came with OS X 10.10.1 and now the installation of lapack-3.5.0 will not load properly. I am getting the following error:

MossPiglet% make
( cd INSTALL; /Applications/Xcode.app/Contents/Developer/usr/bin/make; ./testlsame; ./testslamch; ./testdlamch; \
./testsecond; ./testdsecnd; ./testieee; ./testversion )
gfortran -o testlsame lsame.o lsametst.o
gfortran: warning: couldn't understand kern.osversion '14.0.0
ld: library not found for -lcrt1.o
collect2: error: ld returned 1 exit status
make[1]: *** [testlsame] Error 1
ASCII character set
Tests completed
Epsilon = 5.96046448E-08
Safe minimum = 1.17549435E-38
Base = 2.00000000
Precision = 1.19209290E-07
Number of digits in mantissa = 24.0000000
Rounding mode = 1.00000000
Minimum exponent = -125.000000
Underflow threshold = 1.17549435E-38
Largest exponent = 128.000000
Overflow threshold = 3.40282347E+38
Reciprocal of safe minimum = 8.50705917E+37
Epsilon = 1.1102230246251565E-016
Safe minimum = 2.2250738585072014E-308
Base = 2.0000000000000000
Precision = 2.2204460492503131E-016
Number of digits in mantissa = 53.000000000000000
Rounding mode = 1.0000000000000000
Minimum exponent = -1021.0000000000000
Underflow threshold = 2.2250738585072014E-308
Largest exponent = 1024.0000000000000
Overflow threshold = 1.7976931348623157E+308
Reciprocal of safe minimum = 4.4942328371557898E+307
Time for 0.100E+09 SAXPY ops = 0.100E-05 seconds
SAXPY performance rate = 0.100E+09 mflops
Including SECOND, time = 0.428E-02 seconds
Average time for SECOND = 0.855E-04 milliseconds
Equivalent floating point ops = 0.855E+07 ops
Time for 0.100E+09 DAXPY ops = 0.100E-05 seconds
DAXPY performance rate = 0.100E+09 mflops
Including DSECND, time = 0.434E-02 seconds
Average time for DSECND = 0.868E-04 milliseconds
Equivalent floating point ops = 0.868E+07 ops
We are about to check whether infinity arithmetic
can be trusted. If this test hangs, set
ILAENV = 0 for ISPEC = 10 in LAPACK/SRC/ilaenv.f

Infinity arithmetic performed as per the ieee spec.
However, this is not an exhaustive test and does not
guarantee that infinity arithmetic meets the ieee spec.

We are about to check whether NaN arithmetic
can be trusted. If this test hangs, set
ILAENV = 0 for ISPEC = 11 in LAPACK/SRC/ilaenv.f

NaN arithmetic performed as per the ieee spec.
However, this is not an exhaustive test and does not
guarantee that NaN arithmetic meets the ieee spec.

LAPACK 3 . 5 . 0
( cd SRC; /Applications/Xcode.app/Contents/Developer/usr/bin/make )
make[1]: Nothing to be done for `all'.
( cd TESTING/MATGEN; /Applications/Xcode.app/Contents/Developer/usr/bin/make )
make[1]: Nothing to be done for `all'.
( cd BLAS/TESTING; /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makeblat1 )
gfortran sblat1.o \
../../librefblas.a -o ../xblat1s
gfortran: warning: couldn't understand kern.osversion '14.0.0
ld: library not found for -lcrt1.o
collect2: error: ld returned 1 exit status
make[1]: *** [../xblat1s] Error 1
make: *** [blas_testing] Error 2

Am I doing something wrong?

Thanks,

Rich

[admin]

Rich,
I would advice to upgrade Xcode and your GCC compilers.
It should help.
Julie

[richwolski]

Thanks Julie. I'm already upgraded to the latest version of Xcode (which brings with it gcc). Things are definitely different. For example, gcc no longer includes /usr/local in its default search paths for header and library files.

Other thoughts?

Rich

[admin]

Just google your issue. you are not the only one with that issue.
I would maybe restart with a fresh download of LAPACK
Check the fortran version you are using.

I am using a mac also (Yosemite 10.10.1) , I have no problem with my GCC compiler - I am using gfortran version 4.8.3 from macport
my Xcode is 6.1.1

Hope it helps

[richwolski]

Okay -- thanks. Those are my specs. I have fortran 4.8.3 installed and Xcode 6.1.1. I'll blow the install away and re-install to see if that cures the issue. I did a make clean and that didn't clear it.

Perhaps there should be a distclean target in the makefile to allow one to start over?

Rich

[richwolski]

Okay -- I got it to work. It took a little doing. Here is the situation.

OSX 10.10.1, Xcode 6.1.1, Homebrew, Macbook Pro 2.8GHz i7, lapack-3.5.0

Step 1 -- Fix Homebrew

I've been using gfortran to build lapack on OS X from homebrew. OS X 10.10 (or, more properly Xcode 6.1.1) has changed the ruby interpreter so that the version of Homebrew that was install when I upgraded from Mavericks no longer works. There are several how-tos on this subject. I used

http://apple.stackexchange.com/question ... o-yosemite

and it worked pretty well.

Step 2 -- install gcc

Homebrew has bundled fortran with gcc at its current release. After getting it squared away, I needed to do

brew install gcc

Step 3 -- build lapack

I don't recall if it was the case before but this time around I needed to make blaslib, lapack, and lapacke separately. I do notice that the version of gcc that comes with Xcode 6.1.1 has changed a few things with respect to the "standard" searches for libraries and include files. Perhaps make handles dependencies differently. However when I type "make" in the top level lapack-3.5.0 from a clean install, it doesn't build entirely. Instead I needed to

cd lapack-3.5.0
make blaslib
make
cd lapacke
make

There appears to be a loader warning as well. When I build, ld prints



Step 4 -- path to libgfortran.a

Lastly, I needed to set the path to libgfortran.a explicitly in the makefile that is building the application I'm using with lapack. Homebrew puts it in

/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9/

on my Mac so I added a -L directive to the build lines passed to gcc.

Also I'm getting a loader warning when I load lapack with the application:

ld: warning: could not create compact unwind for _dormlq_: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _dormqr_: stack subq instruction is too different from dwarf stack size

Apparently this is a common warning now with gcc and OS X 10.10 and the application tests all pass but it is unnerving.