What happens if you run `gfortran` from your shell?

On Sun, Dec 21, 2014 at 8:50 PM, Sebastian Good <
[email protected]> wrote:

> Thanks for the hint. Unfortunately, rebuilding blas etc. results in some
> errors; the "No such file or directory" leave me worried. (There's no
> evidence there are problems with pthreads or SandyBridge, and in any case
> just trying the rebuild with the suggested options resulted in the same
> errors. Any ideas what file or directory gfortran might be looking for?
>
> ...
> setparam_HASWELL.c:677:7: warning: unused variable 'l2' [-Wunused-variable]
>   int l2 = get_l2_size();
>       ^
> 1 warning generated.
> make[5]: gfortran: No such file or directory
> make[5]: gfortran: No such file or directory
> make[5]: gfortran: No such file or directory
> make[5]: gfortran: No such file or directory
> make[5]: *** [sgbcon.o] Error 1
> make[5]: *** Waiting for unfinished jobs....
> make[5]: *** [sgbbrd.o] Error 1
> make[5]: *** [sgbequ.o] Error 1
> make[5]: *** [sgbrfs.o] Error 1
> make[4]: *** [lapacklib] Error 2
> make[3]: *** [netlib] Error 2
> *** 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.13/libopenblas.dylib] Error 1
> make[1]: *** [julia-release] Error 2
> make: *** [release] Error 2
>
>
> *Sebastian Good*
>
>
> On Sun, Dec 21, 2014 at 9:59 PM, Isaiah Norton <[email protected]>
> wrote:
>
>> Not sure if this applies to your setup, but see:
>> https://github.com/JuliaLang/julia/issues/9407#issuecomment-67654090
>>
>> On Sun, Dec 21, 2014 at 10:39 PM, Sebastian Good <
>> [email protected]> wrote:
>>
>>> For many months I've enjoyed followed along with the 0.4 development,
>>> but in the last week the build doesn't seem to be working on OS X Yosemite.
>>> I get what appear to be a bunch of lapack link errors. Whether compiling
>>> with gcc or clang the errors seem to be the same; is there some new tooling
>>> or build steps that need to be in place?
>>>
>>> Making install in .
>>>  ./install-sh -c -d '/Users/sebastian/julia/usr/lib'
>>>  /bin/sh ./libtool   --mode=install /usr/bin/install -c   libarpack.la
>>> '/Users/sebastian/julia/usr/lib'
>>> libtool: install: /usr/bin/install -c .libs/libarpack.2.dylib
>>> /Users/sebastian/julia/usr/lib/libarpack.2.dylib
>>> libtool: install: (cd /Users/sebastian/julia/usr/lib && { ln -s -f
>>> libarpack.2.dylib libarpack.dylib || { rm -f libarpack.dylib && ln -s
>>> libarpack.2.dylib libarpack.dylib; }; })
>>> libtool: install: /usr/bin/install -c .libs/libarpack.lai
>>> /Users/sebastian/julia/usr/lib/libarpack.la
>>> libtool: install: /usr/bin/install -c .libs/libarpack.a
>>> /Users/sebastian/julia/usr/lib/libarpack.a
>>> libtool: install: chmod 644 /Users/sebastian/julia/usr/lib/libarpack.a
>>> libtool: install: ranlib /Users/sebastian/julia/usr/lib/libarpack.a
>>>  ./install-sh -c -d '/Users/sebastian/julia/usr/lib/pkgconfig'
>>>  /usr/bin/install -c -m 644 arpack.pc
>>> '/Users/sebastian/julia/usr/lib/pkgconfig'
>>> Making install in TESTS
>>> Making install in EXAMPLES
>>> Making install in BAND
>>> Making install in COMPLEX
>>> Making install in NONSYM
>>> Making install in SIMPLE
>>> Making install in SVD
>>> Making install in SYM
>>> Undefined symbols for architecture x86_64:
>>>   "_dgemm_", referenced from:
>>>       _cholmod_super_numeric in libcholmod.a(cholmod_super_numeric.o)
>>>       _cholmod_super_lsolve in libcholmod.a(cholmod_super_solve.o)
>>>       _cholmod_super_ltsolve in libcholmod.a(cholmod_super_solve.o)
>>>       _cholmod_l_super_numeric in libcholmod.a(cholmod_l_super_numeric.o)
>>>       _cholmod_l_super_lsolve in libcholmod.a(cholmod_l_super_solve.o)
>>>       _cholmod_l_super_ltsolve in libcholmod.a(cholmod_l_super_solve.o)
>>>   "_dgemv_", referenced from:
>>> (etc)
>>>
>>
>>
>

Reply via email to