Problems compiling julia on os x 10.6.8

[sje30]

FOr the last few weeks, I've been having problems updating julia from git. With today's git, I'm still getting errors. I've tried

make

make USE_SYSTEM_BLAS=1 

make USE_SYSTEM_BLAS=1  USE_SYSTEM_LAPACK=1

all of which error. e.g. here is the error for the last call:

a - spqr_tol.o
/usr/bin/ranlib: file: libspqr.a(spqr_parallel.o) has no symbols
/usr/bin/ranlib: file: libspqr.a(spqr_debug.o) has no symbols
ranlib: file: libspqr.a(spqr_parallel.o) has no symbols
ranlib: file: libspqr.a(spqr_debug.o) has no symbols
ar: creating archive librbio.a
a - RBio.o
ld: library not found for -lgfortblas
collect2: ld returned 1 exit status
make[2]: *** [/Users/stephen/NOBACKUP/compiles/julia/usr/lib/libspqr.dylib] Error 1
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

Any clues? It used to work on my system up until a few weeks ago.

[ViralBShah]

You should not do USE_SYSTEM_LAPACK=1 on mac, as the system lapack is old and will fail our tests. Can you post the output for a clean make and make USE_SYSTEM_BLAS=1?

It seems like it is not compiling the gfortblas wrapper.

[sje30]

You should not do USE_SYSTEM_LAPACK=1 on mac, as the system lapack is old and will fail our tests. Can you post the output for a clean make and make USE_SYSTEM_BLAS=1?

This is the end of "make" (have a longer log if you want to see it)

~/NOBACKUP/compiles/julia $ make
../kernel/x86_64/sgemm_kernel_8x8_sandy.S:241:no such instruction: `vzeroupper'
../kernel/x86_64/sgemm_kernel_8x8_sandy.S:243:../kernel/x86_64/sgemm_kernel_8x8_sandy.S:241:no such instruction: `vzeroupper'
../kernel/x86_64/sgemm_kernel_8x8_sandy.S:243:no such instruction: `vmovlps %xmm

... many similar lines omitted ...

../kernel/x86_64/sgemm_kernel_8x8_sandy.S:3676:no such instruction: `vmovss %xmm15, 0*4(%rbx)'
../kernel/x86_64/sgemm_kernel_8x8_sandy.S:3703:no such instruction: `vzeroupper'
make[4]: *** [strmm_kernel_LN_SANDYBRIDGE.o] Error 1
make[3]: *** [libs] Error 1
*** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were errors building SandyBridge support. Both these options can also be used simultaneously. ***
make[2]: *** [openblas-v0.2.8/libopenblas.dylib] Error 1
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

and this is the end of "make USE_SYSTEM_BLAS=1" from a fresh git.

Making install in tune
 /usr/local/bin/gmkdir -p '/Users/stephen/NOBACKUP/compiles/t2/julia/usr/share/doc/mpfr'
 /usr/local/bin/gmkdir -p '/Users/stephen/NOBACKUP/compiles/t2/julia/usr/share/doc/mpfr/examples'
 /usr/local/bin/ginstall -c -m 644  examples/ReadMe examples/divworst.c examples/rndo-add.c examples/sample.c examples/version.c '/Users/stephen/NOBACKUP/compiles/t2/julia/usr/share/doc/mpfr/examples'
 /usr/local/bin/ginstall -c -m 644  AUTHORS BUGS COPYING COPYING.LESSER NEWS TODO '/Users/stephen/NOBACKUP/compiles/t2/julia/usr/share/doc/mpfr/.'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1268k  100 1268k    0     0   477k      0  0:00:02  0:00:02 --:--:--  821k
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 6023k  100 6023k    0     0   519k      0  0:00:11  0:00:11 --:--:--  184k
/bin/sh: ../../../dlasd4-lapack-3.4.2.patch: No such file or directory
make[2]: *** [lapack-3.4.2/Makefile] Error 1
make[1]: *** [julia-release] Error 2

[ViralBShah]

Ok. This is happening because the compiler is too old on 10.6.8. Can you build with make OPENBLAS_TARGET_ARCH=NEHALEM? We should probably do this automatically in our Makefile for 10.6 systems.

The other one is a recent breakage caused by my patch, which I am fixing right away.

[ViralBShah]

I have fixed both the issues. It would be great if you could just build with make and verify it goes through, and also with make USE_SYSTEM_BLAS=1.

[sje30]

Thanks, will test and reply.

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[sje30]

Have now tested -- good news and bad news.

Bad news first: "make" on its own, still fails, with same error:

./kernel/x86_64/sgemm_kernel_8x8_sandy.S:3703:no such instruction: `vzeroupper'
make[4]: *** [sgemm_kernel_SANDYBRIDGE.o] Error 1
make[4]: *** Waiting for unfinished jobs....
make[3]: *** [libs] Error 1
*** Clean the OpenBLAS build with 'make -C deps clean-openblas'. Rebuild with 'make OPENBLAS_USE_THREAD=0 if OpenBLAS had trouble linking libpthread.so, and with 'make OPENBLAS_TARGET_ARCH=NEHALEM' if there were errors building SandyBridge support. Both these options can also be used simultaneously. ***
make[2]: *** [openblas-v0.2.8/libopenblas.dylib] Error 1
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

Good news: "make USE_SYSTEM_BLAS=1" works.

Let me know if you want to do further testing. Thanks for fixing this up so quickly.

[vtjnash]

@ViralBShah the problem probably isn't architecture detection, but that it tries to always build for all architectures

[ViralBShah]

Ah yes. We should disable dynamuc arch snow leopard too.

[sje30]

Ah yes. We should disable dynamuc arch snow leopard too.

Do you want me to test anything new for 10.6?

[ViralBShah]

Could you try make OPENBLAS_DYNAMIC_ARCH=0? That should work, and once you confirm, I will add it as the default configuration for Snow Leopard.

[sje30]

Could you try make OPENBLAS_DYNAMIC_ARCH=0? That should work, and
once you confirm, I will add it as the default configuration for Snow
Leopard.
Yes, that works on snow leopard -- thanks!

[BobPortmann]

I don't think this issue was truly fixed on 10.6.8. As @sje30 found above if I set USE_SYSTEM_BLAS=1 I can compile julia but then it fails make testall (multiple failures, will post if anyone desires). If I use USE_SYSTEM_BLAS=0 (the default) then I get the error reported above (at "bad new first").

[staticfloat]

@sje30's error above is because OpenBLAS is being built with gcc. GCC's assembler doesn't know about AVX, so the hand-assembly in OpenBLAS can't be assembled. Try compiling with USECLANG=1 defined.

@BobPortmann, can you try compiling with USE_SYSTEM_BLAS=1 USE_BLAS64=0? If that doesn't work, posting the full error logs would help us figure out what's going on. If the USE_BLAS64=0 isn't a part of the documentation for building against Accelerate, it should be, and pull requests to add it in are welcome. :)

[sje30]

Hi. I did a git pull today, and now I again get an error when compiling:

make cleanall
make OPENBLAS_DYNAMIC_ARCH=0

...
libtool: install: /usr/local/bin/ginstall -c .libs/libuv.a /Users/stephen/NOBACKUP/compiles/julia/usr/lib/libuv.a
libtool: install: chmod 644 /Users/stephen/NOBACKUP/compiles/julia/usr/lib/libuv.a
libtool: install: ranlib /Users/stephen/NOBACKUP/compiles/julia/usr/lib/libuv.a
 /usr/local/bin/ginstall -c -m 644 include/uv.h include/uv-errno.h include/tree.h include/uv-unix.h include/uv-darwin.h '/Users/stephen/NOBACKUP/compiles/julia/usr/include'
make[3]: Circular src/libuwind.cxx <- src/libuwind.cxx.o dependency dropped.
cc1plus: error: unrecognized command line option "-std=c++11"
make[3]: *** [src/libuwind.cxx.o] Error 1
make[2]: *** [libosxunwind-0.0.1-rc3/libosxunwind.dylib] Error 2
make[1]: *** [julia-release] Error 2
make: *** [release] Error 2

[sje30]

Issue #4215 might be related here...