Building with MKL problems

[esd100]

MacBook-Pro:julia esd100$ make -j 4 CC=icc CXX=icpc FC=ifort USE_INTEL_LIBM=1
Submodule 'deps/Rmath' (git://github.com/JuliaLang/Rmath.git) registered for path 'deps/Rmath'
Submodule 'deps/libuv' (git://github.com/JuliaLang/libuv.git) registered for path 'deps/libuv'
Submodule 'deps/openlibm' (git://github.com/JuliaLang/openlibm.git) registered for path 'deps/openlibm'
Submodule 'deps/openspecfun' (git://github.com/JuliaLang/openspecfun.git) registered for path 'deps/openspecfun'
Submodule 'doc/juliadoc' (git://github.com/JuliaLang/JuliaDoc.git) registered for path 'doc/juliadoc'
Cloning into 'deps/Rmath'...
Submodule path 'deps/Rmath': checked out '1864cf7d1fd77e21a9bf8b3a50db6a816f255a0f'
Cloning into 'deps/libuv'...
Submodule path 'deps/libuv': checked out '6649b84058e82f52adbc1a98f0b94b8aff8c467d'
Cloning into 'deps/openlibm'...
Submodule path 'deps/openlibm': checked out '5f4979e5d1ac985a5081a5de873ce42537c5a6ce'
Cloning into 'deps/openspecfun'...
Submodule path 'deps/openspecfun': checked out '13863b3f7dd67aa44cf042a62b740b011940133f'
Cloning into 'doc/juliadoc'...
Submodule path 'doc/juliadoc': checked out '88cb64ff33f25d50244c337cd3c865392a77400a'
Makefile:836: *** "unknown arch for openblas cross-compile: ". Stop.
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

[ivarne]

It looks like your $(ARCH) make variable is not properly set. By default it is set in Make.inc line 283 by the command:

ARCH := $(shell $(CC) -dumpmachine | sed "s/\([^-]*\).*$$/\1/")

What does icc -dumpmachine | sed "s/\([^-]*\).*$$/\1/" print for you?

Why do you set CC=icc? I would guess there are some compatibility issues with the sed script.

[esd100]

Some of the stuff I have come up with by digging around ...

1. Intel compiler chain & MKL: https://groups.google.com/forum/#!topic/julia-dev/CMGE_KZyxIw
2. openBLAS support for Haswell: Haswell supported in current OpenBLAS, but not version packaged with Julia in deps (0.2.6) #3587

In response to your question, "What does icc -dumpmachine | sed "s/([^-]).$$/\1/" print for you?", when I put it into terminal, there is no response. Maybe icc is giving problems?

I am not an expert in building or makefiles, by any means. My distant background is in engineering.

[esd100]

My system specifications are the following:
Processor: 2.6 GHz Intel Core i7 Haswell
Memory: 16 GB 1600 MHz DDR3
Graphics: Intel Iris Pro 1024 MB
Software: OS X 10.9.2 (13C64)

On a separate topic for building, is there a way to tell Julia to utilize the GPU as well?

[esd100]

Also, on the same topic of building, the Julia gitHub source code page says this about using MKL ...
"To use the Intel MKL BLAS and LAPACK libraries, make sure that MKL version 10.3.6 or higher is installed. For a 64-bit architecture, the MKL environment should be set up as:
source /path/to/mkl/bin/mklvars.sh intel64 ilp64
export MKL_INTERFACE_LAYER=ILP64
When building julia, pass the USE_MKL=1 option to make or add the following line to Make.user.
USE_MKL = 1"

I'm not sure I understand what it means to "set the MKL environment". Can you tell me where I do that?

[esd100]

I should probably make a separate post for this question as well, but since it is about building and the issues I am having, I will just add it on here.

The Julia gitHub source code page says this ..., "If you see build failures in OpenBLAS or if you prefer to experiment, you can use the Apple provided BLAS in vecLib by building with USE_SYSTEM_BLAS=1. Julia does not use the Apple provided LAPACK, as it is too old."

What is the difference between Apple BLAS vs OpenBLAS vs Intel BLAS? And, which one should I use?

[esd100]

One last question about building,

The Julia gitHub source code page says this ..., "To perform a parallel build, use make -j N and supply the maximum number of concurrent processes"

If my system, has 1 processor, but 4 cores, should I put N = 4? If my system profiler shows 8 CPUs (i.e. - 4 physical cores and 4 virtual cores), then should I put N = 8, instead?

[ivarne]

The build failure is definitely that icc -dumpmachine does not work have equal output as gcc and clang. I can not remember to have seen icc on the list of supported compillers. It's not unlikely that you will hit more trouble when you have fixed this minor issue, but it might or might not be possible to compile with the intel toolchain. If you are unable to fix this kind of trivial issues, you will probably have to wait until someone fixes the makefiles, so that it happens automatically.

[ivarne]

I'll make an attempt to Number and answer your questions.

1. Yes, icc is giving problems, (probably because those who wrote the makefile does not use it).
2. No, there is currently no way to tell Julia to use the GPU. There are multiple efforts to create interfaces for GPU programming, that can be used from Julia. Some libraries might already call external libraries that utilize the GPU for computation.
3. I am not sure about MKL environment.
4. The difference between the different BLAS implementation is that they have been written by different people, they have different performance characteristics, and they might contain bugs.
5. Parallel builds is a simple way to speed up compilation, by executing multiple processes at the same time. The only way to find out the optimal number is to test, but the guidelines are probably good. Also, parallel builds, makes it hard to find the correct error message, so when the build is failing, it is recommended to not specify -j

[esd100]

Thank you for your help.

Now, I ran ...
MacBook-Pro:julia esd100$ make -j 4
with the following make.user ...
CXX=icpc
CXXFLAGS="-O3"
FC=ifort
FFLAGS=“-O3"

USE_INTEL_LIBM=1
USE_MKL = 1

and got this error ...
Cloning into 'deps/Rmath'...
Submodule path 'deps/Rmath': checked out '1864cf7d1fd77e21a9bf8b3a50db6a816f255a0f'
Cloning into 'deps/libuv'...
Submodule path 'deps/libuv': checked out '6649b84058e82f52adbc1a98f0b94b8aff8c467d'
Cloning into 'deps/openlibm'...
Submodule path 'deps/openlibm': checked out '5f4979e5d1ac985a5081a5de873ce42537c5a6ce'
Cloning into 'deps/openspecfun'...
Submodule path 'deps/openspecfun': checked out '13863b3f7dd67aa44cf042a62b740b011940133f'
Cloning into 'doc/juliadoc'...
Submodule path 'doc/juliadoc': checked out '88cb64ff33f25d50244c337cd3c865392a77400a'

checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes

/Users/esd100/julia/deps/libuv/missing: Unknown --is-lightweight' option Try/Users/esd100/julia/deps/libuv/missing --help' for more information

configure: WARNING: 'missing' script is too old or missing checking for a thread-safe mkdir -p... ./install-sh -c -d checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-apple-darwin13.1.0
checking host system type... x86_64-apple-darwin13.1.0
checking for gcc... clang -stdlib=libc++ -mmacosx-version-min=10.7
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether clang -stdlib=libc++ -mmacosx-version-min=10.7 accepts -g... yes
checking for clang -stdlib=libc++ -mmacosx-version-min=10.7 option to accept ISO100 134 100 134 0 0 227 0 --:--:-- --:--:-- --:--:-- 227 none needed
checking whether clang -stdlib=libc++ -mmacosx-version-min=10.7 understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of clang -stdlib=libc++ -mmacosx-version-min=10.7... gcc3
checking for ar... ar
checking the archiver
checking whether make
checking how to print
checking for a sed that does not truncate output... /usr/bin/sed
6 6848k 6 419k 0 0 433k 0 0:00:15 --:--:-- 0:00:15 433k/usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by clang -stdlib=libc++ -mmacosx-version-min=10.7... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm checking the name lister (/usr/bin/nm) interface... BSD nm checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... yes
(ar) interface... ar
supports nested variables... (cached) yes strings... printf
checking how to convert x86_64-apple-darwin13.1.0 file names to x86_64-apple-darwin13.1.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin13.1.0 file names to toolchain format... func_convert_file_noop
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @file support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from clang -stdlib=libc++ -mmacosx- 0
checking for sysroot... no
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... clang -stdlib=libc++ -mmacosx-version-min=10.7 -E checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for stdint.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs

amos/d1mach.f(80): remark #7922: The value was too small when converting to REAL(KIND=8); the result is in the denormalized range.
DATA DMACH(2) / 1.79D-308 /
----------------------^

checking if clang -stdlib=libc++ -mmacosx-version-min=10.7 supports -fno-rtti -fno-exceptions... yes checking for clang -stdlib=libc++ -mmacosx-version-min=10.7 option to produce PIC... -fno-common -DPIC checking if clang -stdlib=libc++ -mmacosx-version-min=10.7 PIC flag -fno-common -DPIC works... yes checking if clang -stdlib=libc++ -mmacosx-version-min=10.7 static flag -static works... no
[1.79D-308]
checking if clang -stdlib=libc++ -mmacosx-version-min=10.7 supports -c -o file.o... amos/zasyi.f(25): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
yes
checking if clang -stdlib=libc++ -mmacosx-version-min=10.7 supports -c -o file.o... (cached) yes
checking whether the clang -stdlib=libc++ -mmacosx-version-min=10.7 linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... darwin13.1.0 dyld
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking for dlopen in -ldl... amos/zbesk.f(194):
warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL.
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
yes
checking for kstat_lookup in -lkstat... no
checking for kvm_open in -lkvm... amos/zbknu.f(41):
warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
CAZ = ZABS(COMPLEX(ZR,ZI))
-----------------^
no
checking for gethostbyname in -lnsl... no
checking for perfstat_cpu in -lperfstat... no
checking for pthread_mutex_init in -lpthread... yes
checking for socket in -lsocket... no
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for dtrace... dtrace
checking if dtrace works... yes
checking if dtrace should instrument object files... no
checking for pkg-config... no
amos/zuni1.f(56): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
RAST = FN/ZABS(COMPLEX(STR,STI))
---------------------^
checking that generated files are newer than configure... done

configure: creating ./config.status

amos/zunk2.f(108): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
RAST = FN/ZABS(COMPLEX(STR,STI))
-----------------------^
amos/zacai.f(29): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
amos/zbesh.f(211): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
amos/zbuni.f(49): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
STR = ZABS(COMPLEX(CYR(1),CYI(1)))
-----------------^
amos/zkscl.f(28): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AS = ZABS(COMPLEX(S1R,S1I))
------------------^
amos/zrati.f(23): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^

config.status: creating Makefile

amos/zsqrt.f(13): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
ZM = ZABS(COMPLEX(AR,AI))
----------------^

config.status: executing depfiles commands

amos/zuni2.f(88): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
RAST = FN/ZABS(COMPLEX(STR,STI))
---------------------^
amos/zuoik.f(81): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AARG = ZABS(COMPLEX(ARGR,ARGI))
------------------^
amos/zacon.f(105): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZN = ZABS(COMPLEX(ZNR,ZNI))
-----------------^
amos/zbesi.f(195): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
amos/zbinu.f(17): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^

config.status: executing libtool commands

amos/zlog.f(34): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
50 ZM = ZABS(COMPLEX(AR,AI))
----------------^
amos/zs1s2.f(22): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AS1 = ZABS(COMPLEX(S1R,S1I))
-----------------^
kamos/zwrsk.f(42): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
ACW = ZABS(COMPLEX(CWR(2),CWI(2)))
-----------------^
amos/zairy.f(147): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
amos/zbesj.f(189): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
amos/zbiry.f(141): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
-------------------^
amos/zmlri.f(21): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL.[ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
amos/zseri.f(27): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL.[ZABS]
AZ = ZABS(COMPLEX(ZR,ZI))
----------------^
amos/zunhj.f(460): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
AW2 = ZABS(COMPLEX(W2R,W2I))
----------------^ amos/zdiv.f(11): warning #7319:
This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
BM = 1.0D0/ZABS(COMPLEX(BR,BI))
-----------------^
amos/zunk1.f(68): warning #7319: This argument's data type is incompatible with this intrinsic procedure; procedure assumed EXTERNAL. [ZABS]
RAST = FN/ZABS(COMPLEX(STR,STI))

ifort: command line warning #10006: ignoring unknown option '-shared'
Undefined symbols for architecture x86_64:
"MAIN_", referenced from:
_main in for_main.o
"complex", referenced from:
zasyi in zasyi.f.o zbesk in zbesk.f.o zbknu in zbknu.f.o zuni1 in zuni1.f.o zunk2 in zunk2.f.o zacai in zacai.f.o zbesh in zbesh.f.o ...
ld: symbol(s) not found for architecture x86_64
make[3]: *** [libopenspecfun.dylib] Error 1
make[2]: *** [openspecfun/libopenspecfun.dylib] Error 2
make[2]: *** Waiting for unfinished jobs....
Systems-MacBook-Pro:julia esd100$

[esd100]

Interesting. So, I tried just removing the -j 4 and I got a different error...

MacBook-Pro:julia esd100$ make
Cloning into 'deps/Rmath'...
Submodule path 'deps/Rmath': checked out '1864cf7d1fd77e21a9bf8b3a50db6a816f255a0f'
Cloning into 'deps/libuv'...
Submodule path 'deps/libuv': checked out '6649b84058e82f52adbc1a98f0b94b8aff8c467d'
Cloning into 'deps/openlibm'...
Submodule path 'deps/openlibm': checked out '5f4979e5d1ac985a5081a5de873ce42537c5a6ce'
Cloning into 'deps/openspecfun'...
Submodule path 'deps/openspecfun': checked out '13863b3f7dd67aa44cf042a62b740b011940133f'
Cloning into 'doc/juliadoc'...
Submodule path 'doc/juliadoc': checked out '88cb64ff33f25d50244c337cd3c865392a77400a'

patching file dSFMT.h
patching file dSFMT.c
clang: warning: argument unused during compilation: '--param max-inline-insns-single=1800'

icpc: command line warning #10006: ignoring unknown option '-shared'
ld: entry point (_main) undefined. for architecture x86_64
make[2]: *** [/Users/esd100/julia/usr/lib/libgrisu.dylib] Error 1
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

[ivarne]

No surprise that you hit more issues when you use compilers that is not on the list of supported options. Why do you want to use the intel compiler toolchain? It seems like you run into silly problems that you are unable to solve. That is a poor starting point for doing trying to use different tools than everybody else.

PS. I said in my comment above that -j 4 makes the build log unreliable (multiple things happen at once, and the error messages is mixed). I'm not at all surprised that some of the processes continued spewing out errors after the fatal error was printed.

[esd100]

Well,
In the end, what difference does it make if I do it or someone else. I suppose they are silly problems, in that they shouldn't happen, but they are problems nonetheless.

I don't think that it is too far from normal usage to want to use one of the industry's best compilers and math library for an intel processor. See for yourself, http://software.intel.com/en-us/c-compilers/, with nearly 50% boost for fortran and 100% boost for floating point calcs. Also, see the libraries available at http://software.intel.com/en-us/intel-mkl/, and how the performance scales. There is nearly 4-6x speed up in linear algebra routines for factorization in comparison to ATLAS (and I presume it also performs significantly better than OpenBLAS) and nearly 50x speed up in vectorized exponential calculations in comparison to GLIBC.

Moreover, if those performance enhancements are not convincing enough, it seems that if Julia developers are discussing building with MKL on the front page, then they are endorsing the technology. It also seems that Intel developers are interested in Julia, as you can see from their website...http://software.intel.com/en-us/articles/julia-with-intel-mkl-for-improved-performance.

So, there you go. I attempted to answer your questions. Now, maybe we can try and figure out the problems.

[ivarne]

It is a different case to use MKL, than to use the Intel compilers. As I understand the readme, the steps to use MKL is:

1. Ensure MKL is installed somewhere it can be found.
2. Type the two commands from the readme
3. Clean the relevant dependencies make cleanall && make -C deps cleanall
4. make USE_MKL=1

There is nothing about the Intel compilers in the readme, and because of the nature of the first error, I'm pretty sure nobody is actively using them for Julia. To do this, you will probably need someone who can change the makefile in all the places where gcc/clang and icc has different behaviour. Then he will have to go through and fix the C/C++/Fortran code so that it actually work with icc. To do that, it requires someone knowledgeable in makefiles with access to the Intel compiler to spend a unknown amount of time. Then he will have to fix problems every time something breaks, because most patches will not be tested with Intel compilers before they are merged. It would definitely be nice to support more compilers.

[esd100]

Ah, okay.

I was not aware of all of that. I thought most C/C++/Fortran code could be built by both GNU and Intel compilers. That seems awfully unintuitive. I agree, I think that it would be nice to support more compilers.

As this one post showed, initially someone thought it would be rather easy, but then they had difficulty (https://groups.google.com/forum/#!topic/julia-dev/CMGE_KZyxIw).

[ivarne]

Even the simplest things gets really complicated when you require it to work on 3 platforms and that a automatic build script should be able to figure out everything without asking the user. When you add the requirement that it should be maintainable, it becomes next to impossible. C code are generally not portable between compilers and systems, unless it is written with care and regularly tested.

[pao]

I think this is a combination of closed (non-ICC issues) and a dup of #5473 (ICC-related issues). @esd100, please see #5473 (comment) and see if that works for you--if not, please continue discussion related to getting ICC working in that issue.

[StefanKarpinski]

It would definitely be nice to get Julia compiling under a full Intel toolchain, but it's a nontrivial task to port things to a different compiler. Even gcc vs. clang presents difficulties and clang has intentionally been designed to be as gcc-compatible as possible. @esd100, if you're willing to help slog through getting icc to work, that would be much appreciated – you can still get the benefits of MKL without it though.

[esd100]

I doubt I will be very helpful because I am generally too busy with other things (I'm a physician with a background in engineering) and messing around with this kind of stuff is more of a hobby / pass time. If I can figure out #6244 , with just the basics, then I might move on to try and build with MKL. Then, if I can do that, then I might try the intel compilers. However, as I have done a little bit more exploration, I have found that between the three biggest compilers gcc / llvm-clang / intel, there are really difficult challenges to overcome but only mild to modest returns in performance.
To complicate things further, Apple even has it's own subversion of llvm-clang that ships with XCode. (clang 503 based on svn clang 3.4). LLVM-Clang seems to have more momentum in development than GCC, due to its modular nature and it's ability to fit more smoothly into Apple's IDE. Apple has in fact, completely removed GCC from it's XCode toolchain (https://en.wikipedia.org/wiki/Xcode). LLVM-Clang 3.4 also seems to have nearly matched GCC in it's performance, optimizations and C-language feature compatibility (supposedly C++14 feature complete and compatible with at least GCC 4.7 now). One thing I don't understand is that according to this, the intel toolchain should be compatible with GCC on OS X (https://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler). Anyway, right now I am focusing on just getting Julia to work with the basics #6244.

[esd100]

I'm not quite sure why there is not a LLVM-FLANG ("fortran language") but maybe in the future there will be.

[tkelman]

I'm not quite sure why there is not a LLVM-FLANG ("fortran language") but maybe in the future there will be.

A preliminary one was developed as a LLVM GSoC project last year: http://llvm.1065342.n5.nabble.com/GSoC-Flang-s-end-of-GSoC-report-td61430.html

It's not exactly production-ready, but with more work it may get there. I don't think Google or Apple have too much interest in Fortran, which is understandable but unfortunate for the scientific community.

[esd100]

An update.

After successful build with just the basics (see #6272 ), I went back and tried to build using MKL.

The build process went on for a good amount of time, as you can see from the length of the gist, (https://gist.github.com/esd100/9905847) only to fail near the end. :-(

libtool: link: ar cru .libs/libarpacksrc.a .libs/sgetv0.o .libs/slaqrb.o .libs/sstqrb.o .libs/ssortc.o .libs/ssortr.o .libs/sstatn.o .libs/sstats.o .libs/snaitr.o .libs/snapps.o .libs/snaup2.o .libs/snaupd.o .libs/snconv.o .libs/sneigh.o .libs/sngets.o .libs/ssaitr.o .libs/ssapps.o .libs/ssaup2.o .libs/ssaupd.o .libs/ssconv.o .libs/sseigt.o .libs/ssgets.o .libs/sneupd.o .libs/sseupd.o .libs/ssesrt.o .libs/dgetv0.o .libs/dlaqrb.o .libs/dstqrb.o .libs/dsortc.o .libs/dsortr.o .libs/dstatn.o .libs/dstats.o .libs/dnaitr.o .libs/dnapps.o .libs/dnaup2.o .libs/dnaupd.o .libs/dnconv.o .libs/dneigh.o .libs/dngets.o .libs/dsaitr.o .libs/dsapps.o .libs/dsaup2.o .libs/dsaupd.o .libs/dsconv.o .libs/dseigt.o .libs/dsgets.o .libs/dneupd.o .libs/dseupd.o .libs/dsesrt.o .libs/cnaitr.o .libs/cnapps.o .libs/cnaup2.o .libs/cnaupd.o .libs/cneigh.o .libs/cneupd.o .libs/cngets.o .libs/cgetv0.o .libs/csortc.o .libs/cstatn.o .libs/znaitr.o .libs/znapps.o .libs/znaup2.o .libs/znaupd.o .libs/zneigh.o .libs/zneupd.o .libs/zngets.o .libs/zgetv0.o .libs/zsortc.o .libs/zstatn.o
libtool: link: ranlib .libs/libarpacksrc.a
libtool: link: ( cd ".libs" && rm -f "libarpacksrc.la" && ln -s "../libarpacksrc.la" "libarpacksrc.la" )
Making all in .
libtool: link: gfortran -mmacosx-version-min=10.7 -dynamiclib -o .libs/libarpack.2.dylib -Wl,-force_load,./SRC/.libs/libarpacksrc.a -Wl,-force_load,./UTIL/.libs/libarpackutil.a -framework vecLib -mmacosx-version-min=10.7 -O2 -Wl,-rpath -Wl,/Applications/julia/usr/lib -framework vecLib -install_name /Applications/julia/usr/lib/libarpack.2.dylib -compatibility_version 3 -current_version 3.0 -Wl,-single_module
gfortran: fatal error: no input files; unwilling to write output files
compilation terminated.
make[4]: *** [libarpack.la] Error 1
make[3]: *** [all-recursive] Error 1
make[2]: *** [arpack-ng-3.1.3/.libs/libarpack.dylib] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

[esd100]

There has usually been very rapid responses, so, because this is a little unusual, I am just wondering if anyone saw this last update.

[StefanKarpinski]

It's unclear (to me at least) what's going on at this point. Are you trying to make the build work with a broken version of gfortran?

[esd100]

No, sorry I didn't make it clearer. As I referenced 2 posts up, I did have a successful build of Julia with gfortran (see #6272). But, as I also am interested in building other working versions of Julia (see 6 posts up), I decided to delete everything and try to see if I could build Julia another way. After I deleted everything, I downloaded Julia source again and tried make, but OpenBLAS 0.3.8 is still broken and the build failed (as expected. OpenBLAS 0.3.9rc2 minimum is needed for haswell processors. again see #6272). Then, I decided I would try to build Julia using MKL. Which is the experiment above (see 2 posts up), which made it far but failed with the error above.

[esd100]

Perhaps I should just post a new issue.