Mac OS X 10.9 with Intel Fortran compiler: linker error

[jacopo-chevallard]

Hi,

I am trying to compile OpenBLAS (version 0.2.13) on a Mac OS X 10.9.5. The Xcode version is 6.0.1.

Running clang --version I obtain

Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix  

While ifort --version gives

ifort (IFORT) 15.0.1 20141022
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

Compiling OpenBLAS with gfortran doesn't raise any error, while when compiling OpenBLAS with make FC=ifort the compilation goes well, but when linking the test executables I obtain the following error

ranlib ../../../libopenblas_haswell-r0.2.13.a
touch libopenblas_haswell-r0.2.13.a
/Applications/Xcode.app/Contents/Developer/usr/bin/make -j 8 -C test all
ifort -O2 -fPIC -c sblat1.f  -o sblat1.o
ifort -O2 -fPIC -c dblat1.f  -o dblat1.o
ifort -O2 -fPIC -c cblat1.f  -o cblat1.o
ifort -O2 -fPIC -c zblat1.f  -o zblat1.o
ifort -O2 -fPIC -c sblat2.f  -o sblat2.o
ifort -O2 -fPIC -c dblat2.f  -o dblat2.o
ifort -O2 -fPIC -c cblat2.f  -o cblat2.o
ifort -O2 -fPIC -c zblat2.f  -o zblat2.o
ifort -O2 -fPIC -c sblat3.f  -o sblat3.o
ifort -O2 -fPIC -c dblat3.f  -o dblat3.o
ifort -O2 -fPIC -c cblat3.f  -o cblat3.o
ifort -O2 -fPIC -c zblat3.f  -o zblat3.o
ifort -O2   -o sblat1 sblat1.o ../libopenblas_haswell-r0.2.13.a
ifort -O2   -o dblat1 dblat1.o ../libopenblas_haswell-r0.2.13.a
ifort -O2   -o cblat1 cblat1.o ../libopenblas_haswell-r0.2.13.a
ifort -O2   -o zblat1 zblat1.o ../libopenblas_haswell-r0.2.13.a
ld: library not found for -lgcc_s
make[1]: *** [sblat1] Error 1
make[1]: *** Waiting for unfinished jobs....
ld: library not found for -lgcc_s
make[1]: *** [dblat1] Error 1
ld: library not found for -lgcc_s
make[1]: *** [cblat1] Error 1
ld: library not found for -lgcc_s
make[1]: *** [zblat1] Error 1
make: *** [tests] Error 2

In other words, if I run make FC=ifort libs and make FC=ifort netlibs I don't get any error, while make FC=ifort test raises the above error.

If I skip the test step and run make FC=ifort shared I got the following error:

ifort -O2 -fPIC -all_load -headerpad_max_install_names -install_name /Users/jchevall/temp/xianyi-OpenBLAS-aceee4e/exports/../libopenblas_haswell-r0.2.13.dylib -dynamiclib -o ../libopenblas_haswell-r0.2.13.dylib ../libopenblas_haswell-r0.2.13.a -Wl,-exported_symbols_list,osx.def  -L/usr/bin/ifort-15.0-base/compiler/lib -L/usr/lib  -lSystem -lpthread  /usr/bin/ifort-15.0-base/compiler/lib/libifport.a /usr/bin/ifort-15.0-base/compiler/lib/libifcore.a /usr/bin/ifort-15.0-base/compiler/lib/libimf.a /usr/bin/ifort-15.0-base/compiler/lib/libsvml.a /usr/bin/ifort-15.0-base/compiler/lib/libipgo.a /usr/bin/ifort-15.0-base/compiler/lib/libirc.a /usr/bin/ifort-15.0-base/compiler/lib/libsvml.a /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.0/lib/darwin/libclang_rt.osx.a -lgfortran
ld: library not found for -lgfortran
make[1]: *** [libopenblas_haswell-r0.2.13.dylib] Error 1
make: *** [shared] Error 2

Note that I tried to overcome the problem by manually setting DYLD_LIBRARY_PATH and LD_LIBRARY_PATH to the full path of libgcc_s.dylib and libgfortran.dylib (on my machine this path is /usr/local/Cellar/gcc/4.9.1/lib/gcc/x86_64-apple-darwin13.4.0/4.9.1) but I get the same errors.

[xianyi]

Sorry, we didn't test ifort and clang on OS X. I will test this case in weekends.

[xianyi]

@jacopo-chevallard , I am not sure this is OpenBLAS bug.

It looks like the configuration of ifort and Xcode bug.
https://software.intel.com/en-us/forums/topic/533710

Could you try compiling a very simple example by ifort?

[ptosco]

Hi,

I do realise this is an old thread, but since it's still open I'll add a short comment. I just hit the same issue, and in my case I fixed it bumping the MACOSX_DEPLOYMENT_TARGET from 10.2 to 10.5.

Paolo

[xianyi]

I think I already fixed this on develop branch.

2015-09-18 10:06 GMT-05:00 Paolo Tosco notifications@github.com:

Hi,

I realise I am very late on this, but I just hit the same issue, and in my
case I fixed it bumping the MACOSX_DEPLOYMENT_TARGET from 10.2 to 10.5.

Paolo

—
Reply to this email directly or view it on GitHub
#496 (comment).