Julia now builds on master. No longer need to disable threading. Make.user for me is now:
override USE_SYSTEM_BLAS = 1 override LIBBLAS = -L/usr/lib64/atlas -lsatlas override LIBBLASNAME = libsatlas override USE_BLAS64 = 0 -viral > On Jul 19, 2016, at 7:00 PM, Viral Shah <vi...@fourthlion.in> wrote: > > I am testing on CentOS Linux release 7.2.1511 (AltArch) > > This is the line I am using: > export LD_LIBRARY_PATH=/usr/lib64/atlas:$LD_LIBRARY_PATH > > Our README says LAPACK >= 3.5, so I suspect the system lapack won’t work out. > Assuming that symbol is present in the libsatlas file, perhaps try also > copying it in julia’s usr/lib. > > The other thing is to run make again to make sure that all the rpath and > linking stuff has gone through fine. Or perhaps make cleanall and make. > > -viral > > > >> On Jul 19, 2016, at 6:55 PM, James Fairbanks <jpfairba...@gmail.com> wrote: >> >> For completeness I should say that the julia executable appears not to have >> the libjulia.so correctly linked. >> >> $ ./julia >> ./julia: symbol lookup error: /home/jpf/julia/usr/bin/../lib/liblapack.so: >> undefined symbol: lsame_ >> $ ldd ./julia >> linux-vdso64.so.1 => (0x00003fff9d140000) >> libjulia.so.0.5 => not found >> libdl.so.2 => /lib64/libdl.so.2 (0x00003fff9d100000) >> librt.so.1 => /lib64/power8/librt.so.1 (0x00003fff9d0d0000) >> libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x00003fff9d090000) >> libc.so.6 => /lib64/power8/libc.so.6 (0x00003fff9ceb0000) >> /lib64/ld64.so.2 (0x00000000251e0000) >> >> $ ldd ./usr/lib/libjulia.so >> linux-vdso64.so.1 => (0x00003fff99680000) >> libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so >> (0x00003fff97d80000) >> libdl.so.2 => /lib64/libdl.so.2 (0x00003fff97d40000) >> librt.so.1 => /lib64/power8/librt.so.1 (0x00003fff97d10000) >> libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x00003fff97cd0000) >> libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00003fff97b50000) >> libm.so.6 => /lib64/power8/libm.so.6 (0x00003fff97a60000) >> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00003fff97a20000) >> libc.so.6 => /lib64/power8/libc.so.6 (0x00003fff97840000) >> libz.so.1 => /lib64/libz.so.1 (0x00003fff97800000) >> /lib64/ld64.so.2 (0x0000000035a00000) >> >> On Tuesday, July 19, 2016 at 6:30:34 PM UTC-4, James Fairbanks wrote: >> Adding /usr/lib64/atlas was insufficient so I created a symlink in ln -s >> /usr/lib/atlas/libsatlas.so.3 /usr/lib/atlas/libsatlas.so >> This allowed the build process to complete but leads to an error when >> running the julia executable. >> >> The error is: >> /home/jpf/julia/usr/bin/julia: symbol lookup error: >> /home/jpf/julia/usr/bin/../lib/liblapack.so: undefined symbol: lsame_ >> >> Is it a good idea to go with the RHEL ppc64le system lapack instead of >> having julia build lapack against system blas? >> I have this version of lapack available from the system. >> >> Available Packages >> Name : lapack >> Arch : ppc64le >> Version : 3.4.2 >> Release : 5.el7 >> Size : 4.9 M >> Repo : rhel-7-for-power-le-rpms/7Server/ppc64le >> >> >> Thanks, >> James >> On Tuesday, July 19, 2016 at 4:46:22 PM UTC-4, Viral Shah wrote: >> >> Yes - I forgot to mention that. On the machine I am using, I had to add >> /usr/lib64/atlas or something like that to LD_LIBRARY_PATH. I can’t login at >> the moment for some reason, or else I could have retrieved the exact line. >> >> >> -viral >> >> >> >>> On Jul 19, 2016, at 4:12 PM, James Fairbanks <jpfai...@gmail.com> wrote: >>> >>> I set it up like you said and got the following error >>> >>> $ make >>> ... a bunch of stuff successfully building ... >>> /usr/bin/ld: cannot find -lsatlas >>> collect2: error: ld returned 1 exit status >>> make[1]: *** [build/lapack-3.5.0/liblapack.so] Error 1 >>> make: *** [julia-deps] Error 2 >>> >>> Do I need to add something to LD_LIBRARY_PATH in the makefile or bash >>> environment? >>> >>> On Tuesday, July 19, 2016 at 3:59:55 PM UTC-4, Viral Shah wrote: >>> There is some old ATLAS stuff in there to build atlas that hasn’t been used >>> for a very long time. We are going to delete it. If we find this atlas >>> stuff to be generally useful, we can bring it into the Makefile - but I >>> definitely don’t want to support a source build. >>> >>> override USE_SYSTEM_BLAS = 1 >>> override LIBBLAS = -L/usr/lib64/atlas -lsatlas >>> override LIBBLASNAME = libsatlas >>> override USE_BLAS64 = 0 >>> override JULIA_THREADS := 0 >>> >>> Use the vs/ccall-ppc branch that I just pushed, with the above Make.user. >>> Master still doesn’t work. >>> >>> -viral >>> >>> >>>> On Jul 19, 2016, at 3:49 PM, James Fairbanks <jpfai...@gmail.com> wrote: >>>> >>>> You are overriding the SYSTEM_BLAS with ATLAS. There is a USE_ATLAS >>>> option. Sould that work? >>>> >>>> the relevant part from Make.inc is >>>> >>>> USE_ATLAS := 0 >>>> ATLAS_LIBDIR := $(build_libdir) >>>> # or ATLAS_LIBDIR := /path/to/atlas >>>> >>>> >>>> >>>> On Saturday, July 9, 2016 at 2:07:38 AM UTC-4, Viral Shah wrote: >>>> The current master now seems to be in good shape for Power, for those >>>> interested in trying it out. OpenBLAS is still working out a few bugs, but >>>> in the meanwhile, I was able to successfully link against Atlas using the >>>> following Make.user: >>>> >>>> override USE_SYSTEM_BLAS = 1 >>>> override LIBBLAS = -L/usr/lib64/atlas -lsatlas >>>> override LIBBLASNAME = libsatlas >>>> override USE_BLAS64 = 0 >>>> >>>> Apart from multi-threading, all the other tests passed. >>>> >>>> -viral >>>> >>> >> >
