Hi Viral,

uname -a is:
> Linux abc.com 3.10.0-327.18.2.el7.ppc64le #1 SMP Fri Apr 8 05:10:45 EDT
2016 ppc64le ppc64le ppc64le GNU/Linux

and using Power8: Red Hat Enterprise Linux Server release 7.2 (Maipo)


Can you send me the tarball image of Julia compiled in Power8? I would like
to test it if the problem is only during compilation. Since I have no git
access on this machine, I used make -C deps getall to pull the deps before
copying the source files to Power8. It may be possible the deps were not
properly resolved?

On Fri, Jul 22, 2016 at 1:58 PM, Viral Shah <vi...@mayin.org> wrote:

> Not sure what to do here. Is the filesystem NFS or something? Perhaps just
> try building again with make -j 1.
>
> What is uname -a?
>
> -viral
>
> On Jul 22, 2016 8:52 AM, "Paulito Palmes" <ppal...@gmail.com> wrote:
>
>> Hi,
>>
>> I'm compiling using Red Hat Enterprise Linux Server release 7.2 in Power8
>> and I got this error:
>>
>> ./julia/usr/lib64/libunwind*.a: No such file or directory
>>
>> the make process didn't create usr/lib64 and the libunwind*.a are in
>> usr/lib
>>
>> I created the links of libunwind*.a in usr/lib64
>>
>> but got these errors during compile:
>>
>> make[2]: Warning: File
>> `/home/paulpalm/julia/deps/srccache/patchelf-0.9/aclocal.m4' has
>> modification time 293 s in the future
>>
>>  cd /home/paulpalm/julia/deps/srccache/patchelf-0.9 && /bin/sh
>> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing
>> automake-1.15 --foreign
>>
>> /home/paulpalm/julia/deps/srccache/patchelf-0.9/build-aux/missing: line
>> 81: automake-1.15: command not found
>>
>> WARNING: 'automake-1.15' is missing on your system.
>>
>>          You should only need it if you modified 'Makefile.am' or
>>
>>          'configure.ac' or m4 files included by 'configure.ac'.
>>
>>          The 'automake' program is part of the GNU Automake package:
>>
>>          <http://www.gnu.org/software/automake>
>>
>>          It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>>
>>          <http://www.gnu.org/software/autoconf>
>>
>>          <http://www.gnu.org/software/m4/>
>>
>>          <http://www.perl.org/>
>>
>> make[2]: *** [julia/deps/srccache/patchelf-0.9/Makefile.in] Error 1
>>
>> make[1]: *** [build/patchelf-0.9/src/patchelf] Error 2
>>
>> make: *** [julia-deps] Error 2
>>
>> I have automake-1.13 while it looks for automake-1.15.
>>
>> On Wednesday, 20 July 2016 20:57:36 UTC+1, Viral Shah wrote:
>>>
>>> Just a heads up, there is a bug in atlas that causes the linalg/lq test
>>> to fail (thanks Andreas for finding!). The bugfix is going to be in the
>>> next atlas release - 3.10.3
>>>
>>>  https://sourceforge.net/p/math-atlas/bugs/254/#64f2
>>>
>>> Turns out at this moment, both atlas and openblas are not passing
>>> julia’s tests on power.
>>>
>>> -viral
>>>
>>>
>>>
>>> > On Jul 20, 2016, at 3:11 PM, James Fairbanks <jpfai...@gmail.com>
>>> wrote:
>>> >
>>> > Updating to master and using that Make.user worked for me.
>>> >
>>> > Success!
>>> > [jpf@power8 julia-dev]$ ./julia
>>> >                _
>>> >    _       _ _(_)_     |  A fresh approach to technical computing
>>> >   (_)     | (_) (_)    |  Documentation: http://docs.julialang.org
>>> >    _ _   _| |_  __ _   |  Type "?help" for help.
>>> >   | | | | | | |/ _` |  |
>>> >   | | |_| | | | (_| |  |  Version 0.5.0-dev+5549 (2016-07-20 15:47
>>> UTC)
>>> >  _/ |\__'_|_|_|\__'_|  |  Commit 80fcb57 (0 days old master)
>>> > |__/                   |  ppc64le-redhat-linux
>>> >
>>> > Thanks for going through this with me. Hopefully it will be easier for
>>> the next person.
>>> >
>>> > On Wednesday, July 20, 2016 at 10:27:27 AM UTC-4, Viral Shah wrote:
>>> >
>>> > 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 <jpfai...@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
>>> > >>>>
>>> > >>>
>>> > >>
>>> > >
>>> >
>>>
>>>

Reply via email to