Re: [julia-users] IBM Power port

[James Fairbanks]

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  > 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 
> > 
>
>

Re: [julia-users] IBM Power port

[Viral Shah]

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  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
> 

Re: [julia-users] IBM Power port

[Viral Shah]

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  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  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 
> > 
> 

Re: [julia-users] IBM Power port

[James Fairbanks]

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  > 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  
> 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 
> > > 
> > 
>
>

Re: [julia-users] IBM Power port

[James Fairbanks]

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 =>  (0x3fff9d14)
libjulia.so.0.5 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10)
librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d)
libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff9d09)
libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb)
/lib64/ld64.so.2 (0x251e)
 
$ ldd ./usr/lib/libjulia.so
linux-vdso64.so.1 =>  (0x3fff9968)
libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
(0x3fff97d8)
libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4)
librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1)
libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff97cd)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5)
libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2)
libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784)
libz.so.1 => /lib64/libz.so.1 (0x3fff9780)
/lib64/ld64.so.2 (0x35a0)

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  
>> 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  
>> 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 
>> > > 
>> > 
>>
>>

Re: [julia-users] IBM Power port

[Viral Shah]

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  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  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 =>  (0x3fff9d14)
>>libjulia.so.0.5 => not found
>>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10)
>>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d)
>>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff9d09)
>>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb)
>>/lib64/ld64.so.2 (0x251e)
>> 
>> $ ldd ./usr/lib/libjulia.so
>>linux-vdso64.so.1 =>  (0x3fff9968)
>>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
>> (0x3fff97d8)
>>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4)
>>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1)
>>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff97cd)
>>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5)
>>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6)
>>libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2)
>>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784)
>>libz.so.1 => /lib64/libz.so.1 (0x3fff9780)
>>/lib64/ld64.so.2 (0x35a0)
>> 
>> 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  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  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 
 
 
 
>

Re: [julia-users] IBM Power port

[James Fairbanks]

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  > 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  > 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 =>  (0x3fff9d14) 
> >>libjulia.so.0.5 => not found 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff9d09) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb) 
> >>/lib64/ld64.so.2 (0x251e) 
> >> 
> >> $ ldd ./usr/lib/libjulia.so 
> >>linux-vdso64.so.1 =>  (0x3fff9968) 
> >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
> (0x3fff97d8) 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff97cd) 
> >>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5) 
> >>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6) 
> >>libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784) 
> >>libz.so.1 => /lib64/libz.so.1 (0x3fff9780) 
> >>/lib64/ld64.so.2 (0x35a0) 
> >> 
> >> 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  
> 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 b

Re: [julia-users] IBM Power port

[Viral Shah]

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  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  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  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 =>  (0x3fff9d14) 
> >>libjulia.so.0.5 => not found 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff9d09) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb) 
> >>/lib64/ld64.so.2 (0x251e) 
> >> 
> >> $ ldd ./usr/lib/libjulia.so 
> >>linux-vdso64.so.1 =>  (0x3fff9968) 
> >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
> >> (0x3fff97d8) 
> >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4) 
> >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1) 
> >>libpthread.so.0 => /lib64/power8/libpthread.so.0 (0x3fff97cd) 
> >>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5) 
> >>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6) 
> >>libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2) 
> >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9784) 
> >>libz.so.1 => /lib64/libz.so.1 (0x3fff9780) 
> >>/lib64/ld64.so.2 (0x35a0) 
> >> 
> >> 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  wrote: 
> >>> 
> >>> I set it up like you said and got the following error 
> >>> 
> >>> $ make 
> >>> ... a bunch of stu

Re: [julia-users] IBM Power port

[Paulito Palmes]

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:

 

 It also requires GNU Autoconf, GNU m4 and Perl in order to run:

 

 

 

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  > 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  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  
> 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 =>  (0x3fff9d14) 
> > >>libjulia.so.0.5 => not found 
> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10) 
> > >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d) 
> > >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff9d09) 
> > >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb) 
> > >>/lib64/ld64.so.2 (0x251e) 
> > >> 
> > >> $ ldd ./usr/lib/libjulia.so 
> > >>linux-vdso64.so.1 =>  (0x3fff9968) 
> > >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so 
> (0x3fff97d8) 
> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4) 
> > >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1) 
> > >>libpthread.so.0 => /lib64/power8/libpthread.so.0 
> (0x3fff97cd) 
> > >>libstdc++.so.6 => /lib64/libstdc++.so.6 (0x3fff97b5) 
> > >>libm.so.6 => /lib64/power8/libm.so.6 (0x3fff97a6) 
> > >>libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x3fff97a2) 

Re: [julia-users] IBM Power port

[Viral Shah]

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"  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:
>
>  
>
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>
>  
>
>  
>
>  
>
> 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 
>> 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  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 
>> 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 =>  (0x3fff9d14)
>> > >>libjulia.so.0.5 => not found
>> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff9d10)
>> > >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff9d0d)
>> > >>libpthread.so.0 => /lib64/power8/libpthread.so.0
>> (0x3fff9d09)
>> > >>libc.so.6 => /lib64/power8/libc.so.6 (0x3fff9ceb)
>> > >>/lib64/ld64.so.2 (0x251e)
>> > >>
>> > >> $ ldd ./usr/lib/libjulia.so
>> > >>linux-vdso64.so.1 =>  (0x3fff9968)
>> > >>libLLVM-3.8.so => /home/jpf/julia/./usr/lib/libLLVM-3.8.so
>> (0x3fff97d8)
>> > >>libdl.so.2 => /lib64/libdl.so.2 (0x3fff97d4)
>> > >>librt.so.1 => /lib64/power8/librt.so.1 (0x3fff97d1)
>> > >>libpthread.s

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi,

Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP
Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux

Red Hat Enterprise Linux Server release 7.2 (Maipo)
--
make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
MAKE_NB_JOBS=0
dynamic.c: In function ‘support_avx’:
dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
[-Wimplicit-function-declaration]
   cpuid(1, &eax, &ebx, &ecx, &edx);
   ^
dynamic.c:97:3: error: impossible register constraint in ‘asm’
   __asm__ __volatile__
   ^
make[3]: *** [dynamic.o] Error 1
make[2]: *** [libs] Error 1
\033[33;1m*** 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. ***\033[0m
make[1]: ***
[build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
Error 1
make: *** [julia-deps] Error 2
--

On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes  wrote:

> 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  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"  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:
>>>
>>>  
>>>
>>>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>>>
>>>  
>>>
>>>  
>>>
>>>  
>>>
>>> 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 
 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, 

Re: [julia-users] IBM Power port

[Paulito Palmes]

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  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"  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:
>>
>>  
>>
>>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>>
>>  
>>
>>  
>>
>>  
>>
>> 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 
>>> 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 
>>> 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 
>>> 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 =>  (0x3fff9d14000

Re: [julia-users] IBM Power port

[Paulito Palmes]

Ah, forgot to update Make.user


On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:

> Hi,
>
> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1
> SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> --
> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
> MAKE_NB_JOBS=0
> dynamic.c: In function ‘support_avx’:
> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
> [-Wimplicit-function-declaration]
>cpuid(1, &eax, &ebx, &ecx, &edx);
>^
> dynamic.c:97:3: error: impossible register constraint in ‘asm’
>__asm__ __volatile__
>^
> make[3]: *** [dynamic.o] Error 1
> make[2]: *** [libs] Error 1
> \033[33;1m*** 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. ***\033[0m
> make[1]: ***
> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
> Error 1
> make: *** [julia-deps] Error 2
> --
>
> On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes  wrote:
>
>> 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  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"  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:

  

  It also requires GNU Autoconf, GNU m4 and Perl in order to run:

  

  

  

 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 
> 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

Re: [julia-users] IBM Power port

[Viral Shah]

Did it go through? I usually build with make -j 20 on the machines that have 
enough cores. Let me know if you still want me to create the tarball. Using 
ATLAS makes the whole thing a bit nonstandard for creating distributions, but 
I’ll see what I can do if needed.

-viral

> On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
> 
> Ah, forgot to update Make.user
> 
> 
> On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:
> Hi, 
> 
> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP 
> Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> 
> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> --
> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc 
> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1 
> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1 
> MAKE_NB_JOBS=0
> dynamic.c: In function ‘support_avx’:
> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’ 
> [-Wimplicit-function-declaration]
>cpuid(1, &eax, &ebx, &ecx, &edx);
>^
> dynamic.c:97:3: error: impossible register constraint in ‘asm’
>__asm__ __volatile__
>^
> make[3]: *** [dynamic.o] Error 1
> make[2]: *** [libs] Error 1
> \033[33;1m*** 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. ***\033[0m
> make[1]: *** 
> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so] 
> Error 1
> make: *** [julia-deps] Error 2
> --
> 
> On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes  wrote:
> 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  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"  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:
> 
>  
> 
>  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> 
>  
> 
>  
> 
>  
> 
> 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  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 

Re: [julia-users] IBM Power port

[Paulito Palmes]

I'm compiling in both Power7 and Power8 and not yet finished. I started
with make -j 20 but after some time, it had errors. Then I switch to make
-j 1 but takes time to finish. I hope it will compile in both power7 and
power8.

I'll wait and try to check if I can fix some obvious errors. Otherwise,
I'll ask the tarball so that I can check the difference from what I have
specially which objects were not compiled.

thanks.

On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:

> Did it go through? I usually build with make -j 20 on the machines that
> have enough cores. Let me know if you still want me to create the tarball.
> Using ATLAS makes the whole thing a bit nonstandard for creating
> distributions, but I’ll see what I can do if needed.
>
> -viral
>
> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
> >
> > Ah, forgot to update Make.user
> >
> >
> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
> wrote:
> > Hi,
> >
> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1
> SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> >
> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
> > --
> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
> MAKE_NB_JOBS=0
> > dynamic.c: In function ‘support_avx’:
> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
> [-Wimplicit-function-declaration]
> >cpuid(1, &eax, &ebx, &ecx, &edx);
> >^
> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
> >__asm__ __volatile__
> >^
> > make[3]: *** [dynamic.o] Error 1
> > make[2]: *** [libs] Error 1
> > \033[33;1m*** 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. ***\033[0m
> > make[1]: ***
> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
> Error 1
> > make: *** [julia-deps] Error 2
> > --
> >
> > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
> wrote:
> > 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  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"  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:
> >
> >  
> >
> >  It also requires GNU Autoconf, GNU m4 and Perl in order to run:
> >
> >  
> >
> >  
> >
> >  
> >
> > 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 

Re: [julia-users] IBM Power port

[Paulito Palmes]

Here's the error using Power8: same error which happens during linking.

Can you send me the tarballs of successfully compiled image in Power8?

-

LINK usr/lib/libjulia.so.0.5.0
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
make[1]: Warning: File `../src/julia_version.h' has modification time 228 s
in the future
CC ui/repl.o
LINK usr/bin/julia
make[1]: warning:  Clock skew detected.  Your build may be incomplete.
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
LLVM ERROR: unable to evaluate offset to undefined symbol ''
make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error
1
make: *** [julia-inference] Error 2


On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:

> It caused a core-dump during linking ;( in Power7
>
> ...
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> make: *** [julia-inference] Error 2
>
>
> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
>
>> I'm compiling in both Power7 and Power8 and not yet finished. I started
>> with make -j 20 but after some time, it had errors. Then I switch to make
>> -j 1 but takes time to finish. I hope it will compile in both power7 and
>> power8.
>>
>> I'll wait and try to check if I can fix some obvious errors. Otherwise,
>> I'll ask the tarball so that I can check the difference from what I have
>> specially which objects were not compiled.
>>
>> thanks.
>>
>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>>
>>> Did it go through? I usually build with make -j 20 on the machines that
>>> have enough cores. Let me know if you still want me to create the tarball.
>>> Using ATLAS makes the whole thing a bit nonstandard for creating
>>> distributions, but I’ll see what I can do if needed.
>>>
>>> -viral
>>>
>>> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
>>> wrote:
>>> >
>>> > Ah, forgot to update Make.user
>>> >
>>> >
>>> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
>>> wrote:
>>> > Hi,
>>> >
>>> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
>>> #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>>> >
>>> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
>>> > --
>>> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
>>> CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
>>> USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
>>> DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
>>> > dynamic.c: In function ‘support_avx’:
>>> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
>>> [-Wimplicit-function-declaration]
>>> >cpuid(1, &eax, &ebx, &ecx, &edx);
>>> >^
>>> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
>>> >__asm__ __volatile__
>>> >^
>>> > make[3]: *** [dynamic.o] Error 1
>>> > make[2]: *** [libs] Error 1
>>> > \033[33;1m*** 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. ***\033[0m
>>> > make[1]: ***
>>> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
>>> Error 1
>>> > make: *** [julia-deps] Error 2
>>> > --
>>> >
>>> > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
>>> wrote:
>>> > 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  wrote:
>>> > Not sure what to do here. Is the filesystem NFS or something? Perhaps
>>> 

Re: [julia-users] IBM Power port

[Paulito Palmes]

It caused a core-dump during linking ;( in Power7

...
CC src/cgmemmgr.o
LINK usr/lib/libjulia.so.0.5.0
CC ui/repl.o
LINK usr/bin/julia
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
/bin/sh: line 1: 28699 Segmentation fault  (core dumped)
/home/paulpalm/julia/usr/bin/julia -C native --output-ji
/home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
make: *** [julia-inference] Error 2


On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:

> I'm compiling in both Power7 and Power8 and not yet finished. I started
> with make -j 20 but after some time, it had errors. Then I switch to make
> -j 1 but takes time to finish. I hope it will compile in both power7 and
> power8.
>
> I'll wait and try to check if I can fix some obvious errors. Otherwise,
> I'll ask the tarball so that I can check the difference from what I have
> specially which objects were not compiled.
>
> thanks.
>
> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>
>> Did it go through? I usually build with make -j 20 on the machines that
>> have enough cores. Let me know if you still want me to create the tarball.
>> Using ATLAS makes the whole thing a bit nonstandard for creating
>> distributions, but I’ll see what I can do if needed.
>>
>> -viral
>>
>> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
>> >
>> > Ah, forgot to update Make.user
>> >
>> >
>> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
>> wrote:
>> > Hi,
>> >
>> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1
>> SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>> >
>> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
>> > --
>> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc
>> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1
>> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1
>> MAKE_NB_JOBS=0
>> > dynamic.c: In function ‘support_avx’:
>> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
>> [-Wimplicit-function-declaration]
>> >cpuid(1, &eax, &ebx, &ecx, &edx);
>> >^
>> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
>> >__asm__ __volatile__
>> >^
>> > make[3]: *** [dynamic.o] Error 1
>> > make[2]: *** [libs] Error 1
>> > \033[33;1m*** 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. ***\033[0m
>> > make[1]: ***
>> [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
>> Error 1
>> > make: *** [julia-deps] Error 2
>> > --
>> >
>> > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
>> wrote:
>> > 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  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"  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.a

Re: [julia-users] IBM Power port

[Paulito Palmes]

This problem might be specific to Redhat? Unfortunately, I don't have
debian-based Power system running to test.

On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:

> Here's the error using Power8: same error which happens during linking.
>
> Can you send me the tarballs of successfully compiled image in Power8?
>
> -
>
> LINK usr/lib/libjulia.so.0.5.0
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> make[1]: Warning: File `../src/julia_version.h' has modification time 228
> s in the future
> CC ui/repl.o
> LINK usr/bin/julia
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji]
> Error 1
> make: *** [julia-inference] Error 2
>
>
> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
>
>> It caused a core-dump during linking ;( in Power7
>>
>> ...
>> CC src/cgmemmgr.o
>> LINK usr/lib/libjulia.so.0.5.0
>> CC ui/repl.o
>> LINK usr/bin/julia
>> PERL base/pcre_h.jl
>> PERL base/errno_h.jl
>> PERL base/build_h.jl.phony
>> PERL base/fenv_constants.jl
>> PERL base/file_constants.jl
>> PERL base/uv_constants.jl
>> PERL base/version_git.jl.phony
>> JULIA usr/lib/julia/inference.ji
>> /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
>> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
>> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
>> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
>> make: *** [julia-inference] Error 2
>>
>>
>> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes 
>> wrote:
>>
>>> I'm compiling in both Power7 and Power8 and not yet finished. I started
>>> with make -j 20 but after some time, it had errors. Then I switch to make
>>> -j 1 but takes time to finish. I hope it will compile in both power7 and
>>> power8.
>>>
>>> I'll wait and try to check if I can fix some obvious errors. Otherwise,
>>> I'll ask the tarball so that I can check the difference from what I have
>>> specially which objects were not compiled.
>>>
>>> thanks.
>>>
>>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>>>
 Did it go through? I usually build with make -j 20 on the machines that
 have enough cores. Let me know if you still want me to create the tarball.
 Using ATLAS makes the whole thing a bit nonstandard for creating
 distributions, but I’ll see what I can do if needed.

 -viral

 > On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
 wrote:
 >
 > Ah, forgot to update Make.user
 >
 >
 > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
 wrote:
 > Hi,
 >
 > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
 #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
 >
 > Red Hat Enterprise Linux Server release 7.2 (Maipo)
 > --
 > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
 CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
 USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
 DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
 > dynamic.c: In function ‘support_avx’:
 > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
 [-Wimplicit-function-declaration]
 >cpuid(1, &eax, &ebx, &ecx, &edx);
 >^
 > dynamic.c:97:3: error: impossible register constraint in ‘asm’
 >__asm__ __volatile__
 >^
 > make[3]: *** [dynamic.o] Error 1
 > make[2]: *** [libs] Error 1
 > \033[33;1m*** 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. ***\033[0m
 > make[1]: ***
 [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so]
 Error 1
 > make: *** [julia-deps] Error 2
 > --
 >
 > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes 
 wrote:
 > 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

Re: [julia-users] IBM Power port

[Viral Shah]

It appears to me that you are building on some kind of a network filesystem and 
timestamps are getting messed up. Can you build in /tmp or somewhere, which may 
be guaranteed to have local storage and hence avoid these clock issues?

If still doesn’t work, I will create some binaries and upload and put up all 
the instructions. Since openblas still has some issues to be fixed on power, I 
am using an ATLAS build (of which we are using the latest RC), and packaging it 
all up is going to be some work.


-viral



> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
> 
> This problem might be specific to Redhat? Unfortunately, I don't have 
> debian-based Power system running to test.
> 
> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:
> Here's the error using Power8: same error which happens during linking.
> 
> Can you send me the tarballs of successfully compiled image in Power8?
> 
> -
> 
> LINK usr/lib/libjulia.so.0.5.0
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> make[1]: Warning: File `../src/julia_version.h' has modification time 228 s 
> in the future
> CC ui/repl.o
> LINK usr/bin/julia
> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error 1
> make: *** [julia-inference] Error 2
> 
> 
> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
> It caused a core-dump during linking ;( in Power7
> 
> ...  
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> /bin/sh: line 1: 28699 Segmentation fault  (core dumped) 
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji 
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> make: *** [julia-inference] Error 2
> 
> 
> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
> I'm compiling in both Power7 and Power8 and not yet finished. I started with 
> make -j 20 but after some time, it had errors. Then I switch to make -j 1 but 
> takes time to finish. I hope it will compile in both power7 and power8.
> 
> I'll wait and try to check if I can fix some obvious errors. Otherwise, I'll 
> ask the tarball so that I can check the difference from what I have specially 
> which objects were not compiled.
> 
> thanks.
> 
> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
> Did it go through? I usually build with make -j 20 on the machines that have 
> enough cores. Let me know if you still want me to create the tarball. Using 
> ATLAS makes the whole thing a bit nonstandard for creating distributions, but 
> I’ll see what I can do if needed.
> 
> -viral
> 
> > On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
> >
> > Ah, forgot to update Make.user
> >
> >
> > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:
> > Hi,
> >
> > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP 
> > Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> >
> > Red Hat Enterprise Linux Server release 7.2 (Maipo)
> > --
> > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc 
> > FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1 
> > GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1 
> > MAKE_NB_JOBS=0
> > dynamic.c: In function ‘support_avx’:
> > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’ 
> > [-Wimplicit-function-declaration]
> >cpuid(1, &eax, &ebx, &ecx, &edx);
> >^
> > dynamic.c:97:3: error: impossible register constraint in ‘asm’
> >__asm__ __volatile__
> >^
> > make[3]: *** [dynamic.o] Error 1
> > make[2]: *** [libs] Error 1
> > \033[33;1m*** 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. ***\033[0m
> > make[1]: *** 
> > [build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/libopenblas.so] 
> > Error 1
> > make: *** [julia-deps] Error 2
> > --
> >
> > On Fri, Jul 22, 2016 at 3:10 PM, Paulito Palmes  wrote:
> >

Re: [julia-users] IBM Power port

[Viral Shah]

I was able to sucessfully package julia. Files are here. You have to also 
download the libtatlas.so and put it on your LD_LIBRARY_PATH.

https://drive.google.com/folderview?id=0B0rXlkvSbIfhR1RsbUV2VkpFMFk&usp=sharing

-viral



> On Jul 22, 2016, at 2:51 PM, Viral Shah  wrote:
> 
> It appears to me that you are building on some kind of a network filesystem 
> and timestamps are getting messed up. Can you build in /tmp or somewhere, 
> which may be guaranteed to have local storage and hence avoid these clock 
> issues?
> 
> If still doesn’t work, I will create some binaries and upload and put up all 
> the instructions. Since openblas still has some issues to be fixed on power, 
> I am using an ATLAS build (of which we are using the latest RC), and 
> packaging it all up is going to be some work.
> 
> 
> -viral
> 
> 
> 
>> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
>> 
>> This problem might be specific to Redhat? Unfortunately, I don't have 
>> debian-based Power system running to test.
>> 
>> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:
>> Here's the error using Power8: same error which happens during linking.
>> 
>> Can you send me the tarballs of successfully compiled image in Power8?
>> 
>> -
>> 
>>LINK usr/lib/libjulia.so.0.5.0
>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>> make[1]: Warning: File `../src/julia_version.h' has modification time 228 s 
>> in the future
>>CC ui/repl.o
>>LINK usr/bin/julia
>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>>PERL base/pcre_h.jl
>>PERL base/errno_h.jl
>>PERL base/build_h.jl.phony
>>PERL base/fenv_constants.jl
>>PERL base/file_constants.jl
>>PERL base/uv_constants.jl
>>PERL base/version_git.jl.phony
>>JULIA usr/lib/julia/inference.ji
>> LLVM ERROR: unable to evaluate offset to undefined symbol ''
>> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error 1
>> make: *** [julia-inference] Error 2
>> 
>> 
>> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
>> It caused a core-dump during linking ;( in Power7
>> 
>> ...  
>> CC src/cgmemmgr.o
>>LINK usr/lib/libjulia.so.0.5.0
>>CC ui/repl.o
>>LINK usr/bin/julia
>>PERL base/pcre_h.jl
>>PERL base/errno_h.jl
>>PERL base/build_h.jl.phony
>>PERL base/fenv_constants.jl
>>PERL base/file_constants.jl
>>PERL base/uv_constants.jl
>>PERL base/version_git.jl.phony
>>JULIA usr/lib/julia/inference.ji
>> /bin/sh: line 1: 28699 Segmentation fault  (core dumped) 
>> /home/paulpalm/julia/usr/bin/julia -C native --output-ji 
>> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
>> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
>> make: *** [julia-inference] Error 2
>> 
>> 
>> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
>> I'm compiling in both Power7 and Power8 and not yet finished. I started with 
>> make -j 20 but after some time, it had errors. Then I switch to make -j 1 
>> but takes time to finish. I hope it will compile in both power7 and power8.
>> 
>> I'll wait and try to check if I can fix some obvious errors. Otherwise, I'll 
>> ask the tarball so that I can check the difference from what I have 
>> specially which objects were not compiled.
>> 
>> thanks.
>> 
>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>> Did it go through? I usually build with make -j 20 on the machines that have 
>> enough cores. Let me know if you still want me to create the tarball. Using 
>> ATLAS makes the whole thing a bit nonstandard for creating distributions, 
>> but I’ll see what I can do if needed.
>> 
>> -viral
>> 
>>> On Jul 22, 2016, at 10:50 AM, Paulito Palmes  wrote:
>>> 
>>> Ah, forgot to update Make.user
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes  wrote:
>>> Hi,
>>> 
>>> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64 #1 SMP 
>>> Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
>>> 
>>> Red Hat Enterprise Linux Server release 7.2 (Maipo)
>>> --
>>> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/ CC=gcc 
>>> FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY= USE_THREAD=1 
>>> GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1 DYNAMIC_ARCH=1 
>>> MAKE_NB_JOBS=0
>>> dynamic.c: In function ‘support_avx’:
>>> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’ 
>>> [-Wimplicit-function-declaration]
>>>   cpuid(1, &eax, &ebx, &ecx, &edx);
>>>   ^
>>> dynamic.c:97:3: error: impossible register constraint in ‘asm’
>>>   __asm__ __volatile__
>>>   ^
>>> make[3]: *** [dynamic.o] Error 1
>>> make[2]: *** [libs] Error 1
>>> \033[33;1m*** 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=NEHA

Re: [julia-users] IBM Power port

[Paulito Palmes]

great!!! thanks very much

On Fri, Jul 22, 2016 at 8:49 PM, Viral Shah  wrote:

> I was able to sucessfully package julia. Files are here. You have to also
> download the libtatlas.so and put it on your LD_LIBRARY_PATH.
>
>
> https://drive.google.com/folderview?id=0B0rXlkvSbIfhR1RsbUV2VkpFMFk&usp=sharing
>
> -viral
>
>
>
> > On Jul 22, 2016, at 2:51 PM, Viral Shah  wrote:
> >
> > It appears to me that you are building on some kind of a network
> filesystem and timestamps are getting messed up. Can you build in /tmp or
> somewhere, which may be guaranteed to have local storage and hence avoid
> these clock issues?
> >
> > If still doesn’t work, I will create some binaries and upload and put up
> all the instructions. Since openblas still has some issues to be fixed on
> power, I am using an ATLAS build (of which we are using the latest RC), and
> packaging it all up is going to be some work.
> >
> >
> > -viral
> >
> >
> >
> >> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
> >>
> >> This problem might be specific to Redhat? Unfortunately, I don't have
> debian-based Power system running to test.
> >>
> >> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes 
> wrote:
> >> Here's the error using Power8: same error which happens during linking.
> >>
> >> Can you send me the tarballs of successfully compiled image in Power8?
> >>
> >> -
> >>
> >>LINK usr/lib/libjulia.so.0.5.0
> >> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> >> make[1]: Warning: File `../src/julia_version.h' has modification time
> 228 s in the future
> >>CC ui/repl.o
> >>LINK usr/bin/julia
> >> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> >>PERL base/pcre_h.jl
> >>PERL base/errno_h.jl
> >>PERL base/build_h.jl.phony
> >>PERL base/fenv_constants.jl
> >>PERL base/file_constants.jl
> >>PERL base/uv_constants.jl
> >>PERL base/version_git.jl.phony
> >>JULIA usr/lib/julia/inference.ji
> >> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> >> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji]
> Error 1
> >> make: *** [julia-inference] Error 2
> >>
> >>
> >> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes 
> wrote:
> >> It caused a core-dump during linking ;( in Power7
> >>
> >> ...
> >> CC src/cgmemmgr.o
> >>LINK usr/lib/libjulia.so.0.5.0
> >>CC ui/repl.o
> >>LINK usr/bin/julia
> >>PERL base/pcre_h.jl
> >>PERL base/errno_h.jl
> >>PERL base/build_h.jl.phony
> >>PERL base/fenv_constants.jl
> >>PERL base/file_constants.jl
> >>PERL base/uv_constants.jl
> >>PERL base/version_git.jl.phony
> >>JULIA usr/lib/julia/inference.ji
> >> /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> >> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> >> make: *** [julia-inference] Error 2
> >>
> >>
> >> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes 
> wrote:
> >> I'm compiling in both Power7 and Power8 and not yet finished. I started
> with make -j 20 but after some time, it had errors. Then I switch to make
> -j 1 but takes time to finish. I hope it will compile in both power7 and
> power8.
> >>
> >> I'll wait and try to check if I can fix some obvious errors. Otherwise,
> I'll ask the tarball so that I can check the difference from what I have
> specially which objects were not compiled.
> >>
> >> thanks.
> >>
> >> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
> >> Did it go through? I usually build with make -j 20 on the machines that
> have enough cores. Let me know if you still want me to create the tarball.
> Using ATLAS makes the whole thing a bit nonstandard for creating
> distributions, but I’ll see what I can do if needed.
> >>
> >> -viral
> >>
> >>> On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
> wrote:
> >>>
> >>> Ah, forgot to update Make.user
> >>>
> >>>
> >>> On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
> wrote:
> >>> Hi,
> >>>
> >>> Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
> #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> >>>
> >>> Red Hat Enterprise Linux Server release 7.2 (Maipo)
> >>> --
> >>> make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
> CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
> USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
> DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
> >>> dynamic.c: In function ‘support_avx’:
> >>> dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
> [-Wimplicit-function-declaration]
> >>>   cpuid(1, &eax, &ebx, &ecx, &edx);
> >>>   ^
> >>> dynamic.c:97:3: error: impossible register constraint in ‘asm’
> >>>   __asm__ __volatile__
> >>>   ^
> >>> make[3]: *** [dynamic.o] Error 1
> >>> make[2]: *** [libs

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi Viral,

Thanks. I have already informed the sysad to check the time sync of the
servers to avoid future issues.

I'll try to compile in local disks and get back to you.

Yes, I understand it may take some work to create the bin image but highly
appreciate the fact that Julia will run now in power architecture. I think
it was several months ago when a fellow IBMer from US tried to port it in
power machine and had discussion here also but had some issues. It will be
cool if Julia will support power architecture in time for 1.0 release...

On Fri, Jul 22, 2016 at 7:51 PM, Viral Shah  wrote:

> It appears to me that you are building on some kind of a network
> filesystem and timestamps are getting messed up. Can you build in /tmp or
> somewhere, which may be guaranteed to have local storage and hence avoid
> these clock issues?
>
> If still doesn’t work, I will create some binaries and upload and put up
> all the instructions. Since openblas still has some issues to be fixed on
> power, I am using an ATLAS build (of which we are using the latest RC), and
> packaging it all up is going to be some work.
>
>
> -viral
>
>
>
> > On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
> >
> > This problem might be specific to Redhat? Unfortunately, I don't have
> debian-based Power system running to test.
> >
> > On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes 
> wrote:
> > Here's the error using Power8: same error which happens during linking.
> >
> > Can you send me the tarballs of successfully compiled image in Power8?
> >
> > -
> >
> > LINK usr/lib/libjulia.so.0.5.0
> > make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> > make[1]: Warning: File `../src/julia_version.h' has modification time
> 228 s in the future
> > CC ui/repl.o
> > LINK usr/bin/julia
> > make[1]: warning:  Clock skew detected.  Your build may be incomplete.
> > PERL base/pcre_h.jl
> > PERL base/errno_h.jl
> > PERL base/build_h.jl.phony
> > PERL base/fenv_constants.jl
> > PERL base/file_constants.jl
> > PERL base/uv_constants.jl
> > PERL base/version_git.jl.phony
> > JULIA usr/lib/julia/inference.ji
> > LLVM ERROR: unable to evaluate offset to undefined symbol ''
> > make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji]
> Error 1
> > make: *** [julia-inference] Error 2
> >
> >
> > On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes 
> wrote:
> > It caused a core-dump during linking ;( in Power7
> >
> > ...
> > CC src/cgmemmgr.o
> > LINK usr/lib/libjulia.so.0.5.0
> > CC ui/repl.o
> > LINK usr/bin/julia
> > PERL base/pcre_h.jl
> > PERL base/errno_h.jl
> > PERL base/build_h.jl.phony
> > PERL base/fenv_constants.jl
> > PERL base/file_constants.jl
> > PERL base/uv_constants.jl
> > PERL base/version_git.jl.phony
> > JULIA usr/lib/julia/inference.ji
> > /bin/sh: line 1: 28699 Segmentation fault  (core dumped)
> /home/paulpalm/julia/usr/bin/julia -C native --output-ji
> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
> > make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
> > make: *** [julia-inference] Error 2
> >
> >
> > On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes 
> wrote:
> > I'm compiling in both Power7 and Power8 and not yet finished. I started
> with make -j 20 but after some time, it had errors. Then I switch to make
> -j 1 but takes time to finish. I hope it will compile in both power7 and
> power8.
> >
> > I'll wait and try to check if I can fix some obvious errors. Otherwise,
> I'll ask the tarball so that I can check the difference from what I have
> specially which objects were not compiled.
> >
> > thanks.
> >
> > On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
> > Did it go through? I usually build with make -j 20 on the machines that
> have enough cores. Let me know if you still want me to create the tarball.
> Using ATLAS makes the whole thing a bit nonstandard for creating
> distributions, but I’ll see what I can do if needed.
> >
> > -viral
> >
> > > On Jul 22, 2016, at 10:50 AM, Paulito Palmes 
> wrote:
> > >
> > > Ah, forgot to update Make.user
> > >
> > >
> > > On Fri, Jul 22, 2016 at 3:50 PM, Paulito Palmes 
> wrote:
> > > Hi,
> > >
> > > Got this error using Power7: Linux abc.com 3.10.0-327.4.5.el7.ppc64
> #1 SMP Thu Jan 21 04:12:40 EST 2016 ppc64 ppc64 ppc64 GNU/Linux
> > >
> > > Red Hat Enterprise Linux Server release 7.2 (Maipo)
> > > --
> > > make -C build/openblas-12ab1804b6ebcd38b26960d65d254314d8bc33d6/
> CC=gcc FC=gfortran RANLIB=ranlib FFLAGS= -O2 -fPIC TARGET= BINARY=
> USE_THREAD=1 GEMM_MULTITHREADING_THRESHOLD=50 NUM_THREADS=8 NO_AFFINITY=1
> DYNAMIC_ARCH=1 MAKE_NB_JOBS=0
> > > dynamic.c: In function ‘support_avx’:
> > > dynamic.c:107:3: warning: implicit declaration of function ‘cpuid’
> [-Wimplicit-function-declaration]
> > >cpuid(1, &eax, &ebx, &ecx, &edx);
> > >^
> > > dy

Re: [julia-users] IBM Power port

[Viral Shah]

I am hoping we can have beta support from the 0.5 release onwards for 
sequential julia. We were able to do this work due to some small support from 
IBM. Hopefully, as more users use Julia on Power and HPC systems, there may be 
a way to sustain this through the right form of funding. For now, I just keep 
pushing julia on other architectures as a hobby. :-)

-viral

> On Jul 22, 2016, at 3:54 PM, Viral Shah  wrote:
> 
> I am hoping we can have beta support from the 0.5 release onwards for 
> sequential julia. We were able to do this work due to some small support from 
> IBM. Hopefully, as more users use Julia on Power and HPC systems, there may 
> be a way to sustain this through the right form of funding. For now, I just 
> keep building julia on newer architectures as a hobby. :-)
> 
> -viral
> 
> 
> 
>> On Jul 22, 2016, at 3:28 PM, Paulito Palmes  wrote:
>> 
>> Hi Viral,
>> 
>> Thanks. I have already informed the sysad to check the time sync of the 
>> servers to avoid future issues.
>> 
>> I'll try to compile in local disks and get back to you. 
>> 
>> Yes, I understand it may take some work to create the bin image but highly 
>> appreciate the fact that Julia will run now in power architecture. I think 
>> it was several months ago when a fellow IBMer from US tried to port it in 
>> power machine and had discussion here also but had some issues. It will be 
>> cool if Julia will support power architecture in time for 1.0 release...
>> 
>> On Fri, Jul 22, 2016 at 7:51 PM, Viral Shah  wrote:
>> It appears to me that you are building on some kind of a network filesystem 
>> and timestamps are getting messed up. Can you build in /tmp or somewhere, 
>> which may be guaranteed to have local storage and hence avoid these clock 
>> issues?
>> 
>> If still doesn’t work, I will create some binaries and upload and put up all 
>> the instructions. Since openblas still has some issues to be fixed on power, 
>> I am using an ATLAS build (of which we are using the latest RC), and 
>> packaging it all up is going to be some work.
>> 
>> 
>> -viral
>> 
>> 
>> 
>>> On Jul 22, 2016, at 1:50 PM, Paulito Palmes  wrote:
>>> 
>>> This problem might be specific to Redhat? Unfortunately, I don't have 
>>> debian-based Power system running to test.
>>> 
>>> On Fri, Jul 22, 2016 at 6:40 PM, Paulito Palmes  wrote:
>>> Here's the error using Power8: same error which happens during linking.
>>> 
>>> Can you send me the tarballs of successfully compiled image in Power8?
>>> 
>>> -
>>> 
>>>LINK usr/lib/libjulia.so.0.5.0
>>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>>> make[1]: Warning: File `../src/julia_version.h' has modification time 228 s 
>>> in the future
>>>CC ui/repl.o
>>>LINK usr/bin/julia
>>> make[1]: warning:  Clock skew detected.  Your build may be incomplete.
>>>PERL base/pcre_h.jl
>>>PERL base/errno_h.jl
>>>PERL base/build_h.jl.phony
>>>PERL base/fenv_constants.jl
>>>PERL base/file_constants.jl
>>>PERL base/uv_constants.jl
>>>PERL base/version_git.jl.phony
>>>JULIA usr/lib/julia/inference.ji
>>> LLVM ERROR: unable to evaluate offset to undefined symbol ''
>>> make[1]: *** [/home/paulpalm/power8/julia/usr/lib/julia/inference.ji] Error 
>>> 1
>>> make: *** [julia-inference] Error 2
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 5:01 PM, Paulito Palmes  wrote:
>>> It caused a core-dump during linking ;( in Power7
>>> 
>>> ...
>>> CC src/cgmemmgr.o
>>>LINK usr/lib/libjulia.so.0.5.0
>>>CC ui/repl.o
>>>LINK usr/bin/julia
>>>PERL base/pcre_h.jl
>>>PERL base/errno_h.jl
>>>PERL base/build_h.jl.phony
>>>PERL base/fenv_constants.jl
>>>PERL base/file_constants.jl
>>>PERL base/uv_constants.jl
>>>PERL base/version_git.jl.phony
>>>JULIA usr/lib/julia/inference.ji
>>> /bin/sh: line 1: 28699 Segmentation fault  (core dumped) 
>>> /home/paulpalm/julia/usr/bin/julia -C native --output-ji 
>>> /home/paulpalm/julia/usr/lib/julia/inference.ji --startup-file=no coreimg.jl
>>> make[1]: *** [/home/paulpalm/julia/usr/lib/julia/inference.ji] Error 139
>>> make: *** [julia-inference] Error 2
>>> 
>>> 
>>> On Fri, Jul 22, 2016 at 4:48 PM, Paulito Palmes  wrote:
>>> I'm compiling in both Power7 and Power8 and not yet finished. I started 
>>> with make -j 20 but after some time, it had errors. Then I switch to make 
>>> -j 1 but takes time to finish. I hope it will compile in both power7 and 
>>> power8.
>>> 
>>> I'll wait and try to check if I can fix some obvious errors. Otherwise, 
>>> I'll ask the tarball so that I can check the difference from what I have 
>>> specially which objects were not compiled.
>>> 
>>> thanks.
>>> 
>>> On Fri, Jul 22, 2016 at 4:40 PM, Viral Shah  wrote:
>>> Did it go through? I usually build with make -j 20 on the machines that 
>>> have enough cores. Let me know if you still want me to create the tarball. 
>>> Using ATLAS makes the whole thing a bit nonstandard for

Re: [julia-users] IBM Power port

[Paulito Palmes]

HI VIral,

I am also hoping that once IBM sees the potential of Julia+IBM Power for
doing HPC and analytics, they will formally support the Julia development
in the future just like what they did with the docker and other open source
initiatives.

On Fri, Jul 22, 2016 at 9:07 PM, Paulito Palmes  wrote:

> Hi Viral,
>
> Yes, the binary image works without problems in Power8 ;). As expected, it
> complains that it cannot execute in Power7.
>
> I finished compiling in both power7 and power8 using the /tmp. The errors
> are still the same:
>
> Power8:
> --
> CC src/gc.o
> CC src/gc-debug.o
> CC src/gc-pages.o
> CC src/jlapi.o
> CC src/signal-handling.o
> CC src/safepoint.o
> CC src/jloptions.o
> CC src/timing.o
> CC src/codegen.o
> CC src/jitlayers.o
> CC src/disasm.o
> CC src/debuginfo.o
> CC src/llvm-simdloop.o
> CC src/llvm-ptls.o
> CC src/llvm-gcroot.o
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> make[1]: *** [/tmp/julia/usr/lib/julia/inference.ji] Error 1
> make: *** [julia-inference] Error 2
> 
>
>
> Power7:
> ---
>   CC src/signal-handling.o
> CC src/safepoint.o
> CC src/jloptions.o
> CC src/timing.o
> CC src/codegen.o
> CC src/jitlayers.o
> CC src/disasm.o
> CC src/debuginfo.o
> CC src/llvm-simdloop.o
> CC src/llvm-ptls.o
> CC src/llvm-gcroot.o
> CC src/cgmemmgr.o
> LINK usr/lib/libjulia.so.0.5.0
> CC ui/repl.o
> LINK usr/bin/julia
> PERL base/pcre_h.jl
> PERL base/errno_h.jl
> PERL base/build_h.jl.phony
> PERL base/fenv_constants.jl
> PERL base/file_constants.jl
> PERL base/uv_constants.jl
> PERL base/version_git.jl.phony
> JULIA usr/lib/julia/inference.ji
> LLVM ERROR: unable to evaluate offset to undefined symbol ''
> *** Error in `/tmp/julia/usr/bin/julia': free(): invalid pointer:
> 0x01000d27a588 ***
> === Backtrace: =
> /lib64/libc.so.6(+0xaffa4)[0x3fff8a43ffa4]
> /lib64/libstdc++.so.6(_ZdlPv-0xdc2a0)[0x3fff88da9b28]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8884)[0x3fff8a758884]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8978)[0x3fff8a758978]
> /lib64/libc.so.6(__cxa_finalize-0x18145c)[0x3fff8a3f4b04]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x4f118)[0x3fff8a6af118]
> /lib64/ld64.so.1(+0x186c0)[0x3fff8ab586c0]
> /lib64/libc.so.6(+0x6460c)[0x3fff8a3f460c]
> /lib64/libc.so.6(exit-0x1818c4)[0x3fff8a3f464c]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm18report_fatal_errorERKNS_5TwineEb-0xe2c7c4)[0x3fff894930c4]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZNK4llvm11MCAsmLayout15getSymbolOffsetERKNS_8MCSymbolE-0x2064ec)[0x3fff8a10175c]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZNK4llvm11MCAssembler13evaluateFixupERKNS_11MCAsmLayoutERKNS_7MCFixupEPKNS_10MCFragmentERNS_7MCValueERm-0x206338)[0x3fff8a101920]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm11MCAssembler11handleFixupERKNS_11MCAsmLayoutERNS_10MCFragmentERKNS_7MCFixupE-0x205f74)[0x3fff8a101cf4]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm11MCAssembler6FinishEv-0x204fb0)[0x3fff8a102d38]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm16MCObjectStreamer10FinishImplEv-0x1e5d54)[0x3fff8a122e94]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm13MCELFStreamer10FinishImplEv-0x1f2b48)[0x3fff8a115930]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm10MCStreamer6FinishEv-0x1dd0ec)[0x3fff8a12c43c]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm10AsmPrinter14doFinalizationERNS_6ModuleE-0x600d28)[0x3fff89cf0640]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so(+0x43e200)[0x3fff892ee200]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm13FPPassManager14doFinalizationERNS_6ModuleE-0x7a7b98)[0x3fff89b3e2e0]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE-0x79af18)[0x3fff89b4b850]
> /tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
> (_ZN4llvm6legacy11PassManager3runERNS_6ModuleE-0x79ad44)[0x3fff89b4ba34]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x11ed04)[0x3fff8a77ed04]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1260fc)[0x3fff8a7860fc]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x126e4c)[0x3fff8a786e4c]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1270b8)[0x3fff8a7870b8]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xd6e28)[0x3fff8a736e28]
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xdded4)[0x3fff8a73ded4]
>
> /tmp/julia/usr/bin/../lib/libjulia.so.0.5(jl_apply_generic-0x1bbd94)[0x3fff8a6c7fac]
> /tmp/julia

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi Viral,

Yes, the binary image works without problems in Power8 ;). As expected, it
complains that it cannot execute in Power7.

I finished compiling in both power7 and power8 using the /tmp. The errors
are still the same:

Power8:
--
CC src/gc.o
CC src/gc-debug.o
CC src/gc-pages.o
CC src/jlapi.o
CC src/signal-handling.o
CC src/safepoint.o
CC src/jloptions.o
CC src/timing.o
CC src/codegen.o
CC src/jitlayers.o
CC src/disasm.o
CC src/debuginfo.o
CC src/llvm-simdloop.o
CC src/llvm-ptls.o
CC src/llvm-gcroot.o
CC src/cgmemmgr.o
LINK usr/lib/libjulia.so.0.5.0
CC ui/repl.o
LINK usr/bin/julia
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
LLVM ERROR: unable to evaluate offset to undefined symbol ''
make[1]: *** [/tmp/julia/usr/lib/julia/inference.ji] Error 1
make: *** [julia-inference] Error 2



Power7:
---
  CC src/signal-handling.o
CC src/safepoint.o
CC src/jloptions.o
CC src/timing.o
CC src/codegen.o
CC src/jitlayers.o
CC src/disasm.o
CC src/debuginfo.o
CC src/llvm-simdloop.o
CC src/llvm-ptls.o
CC src/llvm-gcroot.o
CC src/cgmemmgr.o
LINK usr/lib/libjulia.so.0.5.0
CC ui/repl.o
LINK usr/bin/julia
PERL base/pcre_h.jl
PERL base/errno_h.jl
PERL base/build_h.jl.phony
PERL base/fenv_constants.jl
PERL base/file_constants.jl
PERL base/uv_constants.jl
PERL base/version_git.jl.phony
JULIA usr/lib/julia/inference.ji
LLVM ERROR: unable to evaluate offset to undefined symbol ''
*** Error in `/tmp/julia/usr/bin/julia': free(): invalid pointer:
0x01000d27a588 ***
=== Backtrace: =
/lib64/libc.so.6(+0xaffa4)[0x3fff8a43ffa4]
/lib64/libstdc++.so.6(_ZdlPv-0xdc2a0)[0x3fff88da9b28]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8884)[0x3fff8a758884]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xf8978)[0x3fff8a758978]
/lib64/libc.so.6(__cxa_finalize-0x18145c)[0x3fff8a3f4b04]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x4f118)[0x3fff8a6af118]
/lib64/ld64.so.1(+0x186c0)[0x3fff8ab586c0]
/lib64/libc.so.6(+0x6460c)[0x3fff8a3f460c]
/lib64/libc.so.6(exit-0x1818c4)[0x3fff8a3f464c]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm18report_fatal_errorERKNS_5TwineEb-0xe2c7c4)[0x3fff894930c4]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZNK4llvm11MCAsmLayout15getSymbolOffsetERKNS_8MCSymbolE-0x2064ec)[0x3fff8a10175c]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZNK4llvm11MCAssembler13evaluateFixupERKNS_11MCAsmLayoutERKNS_7MCFixupEPKNS_10MCFragmentERNS_7MCValueERm-0x206338)[0x3fff8a101920]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm11MCAssembler11handleFixupERKNS_11MCAsmLayoutERNS_10MCFragmentERKNS_7MCFixupE-0x205f74)[0x3fff8a101cf4]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm11MCAssembler6FinishEv-0x204fb0)[0x3fff8a102d38]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm16MCObjectStreamer10FinishImplEv-0x1e5d54)[0x3fff8a122e94]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm13MCELFStreamer10FinishImplEv-0x1f2b48)[0x3fff8a115930]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm10MCStreamer6FinishEv-0x1dd0ec)[0x3fff8a12c43c]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm10AsmPrinter14doFinalizationERNS_6ModuleE-0x600d28)[0x3fff89cf0640]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so(+0x43e200)[0x3fff892ee200]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm13FPPassManager14doFinalizationERNS_6ModuleE-0x7a7b98)[0x3fff89b3e2e0]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm6legacy15PassManagerImpl3runERNS_6ModuleE-0x79af18)[0x3fff89b4b850]
/tmp/julia/usr/bin/../lib/libLLVM-3.7.1.so
(_ZN4llvm6legacy11PassManager3runERNS_6ModuleE-0x79ad44)[0x3fff89b4ba34]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x11ed04)[0x3fff8a77ed04]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1260fc)[0x3fff8a7860fc]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x126e4c)[0x3fff8a786e4c]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x1270b8)[0x3fff8a7870b8]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xd6e28)[0x3fff8a736e28]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xdded4)[0x3fff8a73ded4]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(jl_apply_generic-0x1bbd94)[0x3fff8a6c7fac]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x826a8)[0x3fff8a6e26a8]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x82078)[0x3fff8a6e2078]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x82e1c)[0x3fff8a6e2e1c]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x83368)[0x3fff8a6e3368]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0xa3980)[0x3fff8a703980]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x742e8)[0x3fff8a6d42e8]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(jl_load-0x18170c)[0x3fff8a704474]
/tmp/julia/usr/bin/../lib/libjulia.so.0.5(+0x8e3c8)[0x3f

Re: [julia-users] IBM Power port

[Viral Shah]

It is hard to say what is happening there. Trying it out.

OpenBLAS develop branch is now passing on Power and hence Atlas should no 
longer be required. Note that you need the latest (3.10.4?) ATLAS, but in any 
case, this should not affect the build.

-viral



> On Aug 18, 2016, at 7:03 PM, Geert Janssen  wrote:
> 
> Dear Viral,
> 
> I am building Julie release-0.5 on a Power8E Ubuntu 14.10 machine.
> I use the following Make.user after having had trouble compiling OpenBLAS 
> that was pulled in:
> 
> created Make.user:
> override USE_SYSTEM_BLAS = 1
> override USE_BLAS64 = 0
> override LIBBLAS = -L/opt/atlas/lib -ltatlas
> override LIBBLASNAME = libtatlas
> 
> I get a clean build all the way till the end and then this happens:
> 
> 
> JULIA usr/lib/julia/inference.ji
> /bin/sh: line 1:  6967 Segmentation fault  
> /localhome/geert/src/julia/usr/bin/julia -C native --output-ji 
> /localhome/geert/src/julia/usr/lib/julia/inference.ji --startup-file=no 
> coreimg.jl
> Makefile:215: recipe for target 
> '/localhome/geert/src/julia/usr/lib/julia/inference.ji' failed
> make[1]: *** [/localhome/geert/src/julia/usr/lib/julia/inference.ji] Error 139
> Makefile:96: recipe for target 'julia-inference' failed
> make: *** [julia-inference] Error 2 
> 
> The machine and OS details are:
> 
> geert@tulgpu505:~/src/julia$ lscpu
> Architecture:  ppc64le
> Byte Order:Little Endian
> CPU(s):184
> On-line CPU(s) list:   0-151,160-191
> Thread(s) per core:8
> Core(s) per socket:5
> Socket(s): 4
> NUMA node(s):  4
> Model: 8247-42L
> CPU max MHz:   3923.
> CPU min MHz:   2061.
> L1d cache: 64K
> L1i cache: 32K
> L2 cache:  512K
> L3 cache:  8192K
> NUMA node0 CPU(s): 0-47
> NUMA node1 CPU(s): 48-95
> NUMA node16 CPU(s):96-143
> NUMA node17 CPU(s):144-151,160-191
> geert@tulgpu505:~/src/julia$ cat /etc/os-release 
> NAME="Ubuntu"
> VERSION="14.10 (Utopic Unicorn)"
> ID=ubuntu
> ID_LIKE=debian
> PRETTY_NAME="Ubuntu 14.10"
> VERSION_ID="14.10"
> HOME_URL="http://www.ubuntu.com/";
> SUPPORT_URL="http://help.ubuntu.com/";
> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/";
> geert@tulgpu505:~/src/julia$ uname -a
> Linux tulgpu505 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 UTC 2015 
> ppc64le ppc64le ppc64le GNU/Linux
> geert@tulgpu505:~/src/julia$  
> 
> Any suggestions?
> 
> Thanks,
> 
> Geert

Re: [julia-users] IBM Power port

[Viral Shah]

I am getting successful builds on the OSU Power8 machine. Once openblas has a 
new release, I suspect we can provide pre-packaged power8 binaries. 

I am building on CentOS 7 and this is what lscpu says:

Architecture:  ppc64le
Byte Order:Little Endian
CPU(s):160
On-line CPU(s) list:   0-159
Thread(s) per core:8
Core(s) per socket:10
Socket(s): 2
NUMA node(s):  2
Model: 8335-GCA
L1d cache: 64K
L1i cache: 32K
L2 cache:  512K
L3 cache:  8192K
NUMA node0 CPU(s): 0-79
NUMA node8 CPU(s): 80-159

I suspect you are running into a codegen issue. Let’s give it a few days and 
once llvm 3.9 releases, we can try that. If not, we may need Jameson’s help.

-viral



> On Aug 19, 2016, at 8:54 AM, Viral Shah  wrote:
> 
> It is hard to say what is happening there. Trying it out.
> 
> OpenBLAS develop branch is now passing on Power and hence Atlas should no 
> longer be required. Note that you need the latest (3.10.4?) ATLAS, but in any 
> case, this should not affect the build.
> 
> -viral
> 
> 
> 
>> On Aug 18, 2016, at 7:03 PM, Geert Janssen  wrote:
>> 
>> Dear Viral,
>> 
>> I am building Julie release-0.5 on a Power8E Ubuntu 14.10 machine.
>> I use the following Make.user after having had trouble compiling OpenBLAS 
>> that was pulled in:
>> 
>> created Make.user:
>> override USE_SYSTEM_BLAS = 1
>> override USE_BLAS64 = 0
>> override LIBBLAS = -L/opt/atlas/lib -ltatlas
>> override LIBBLASNAME = libtatlas
>> 
>> I get a clean build all the way till the end and then this happens:
>> 
>>
>>JULIA usr/lib/julia/inference.ji
>> /bin/sh: line 1:  6967 Segmentation fault  
>> /localhome/geert/src/julia/usr/bin/julia -C native --output-ji 
>> /localhome/geert/src/julia/usr/lib/julia/inference.ji --startup-file=no 
>> coreimg.jl
>> Makefile:215: recipe for target 
>> '/localhome/geert/src/julia/usr/lib/julia/inference.ji' failed
>> make[1]: *** [/localhome/geert/src/julia/usr/lib/julia/inference.ji] Error 
>> 139
>> Makefile:96: recipe for target 'julia-inference' failed
>> make: *** [julia-inference] Error 2 
>> 
>> The machine and OS details are:
>> 
>> geert@tulgpu505:~/src/julia$ lscpu
>> Architecture:  ppc64le
>> Byte Order:Little Endian
>> CPU(s):184
>> On-line CPU(s) list:   0-151,160-191
>> Thread(s) per core:8
>> Core(s) per socket:5
>> Socket(s): 4
>> NUMA node(s):  4
>> Model: 8247-42L
>> CPU max MHz:   3923.
>> CPU min MHz:   2061.
>> L1d cache: 64K
>> L1i cache: 32K
>> L2 cache:  512K
>> L3 cache:  8192K
>> NUMA node0 CPU(s): 0-47
>> NUMA node1 CPU(s): 48-95
>> NUMA node16 CPU(s):96-143
>> NUMA node17 CPU(s):144-151,160-191
>> geert@tulgpu505:~/src/julia$ cat /etc/os-release 
>> NAME="Ubuntu"
>> VERSION="14.10 (Utopic Unicorn)"
>> ID=ubuntu
>> ID_LIKE=debian
>> PRETTY_NAME="Ubuntu 14.10"
>> VERSION_ID="14.10"
>> HOME_URL="http://www.ubuntu.com/";
>> SUPPORT_URL="http://help.ubuntu.com/";
>> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/";
>> geert@tulgpu505:~/src/julia$ uname -a
>> Linux tulgpu505 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 UTC 
>> 2015 ppc64le ppc64le ppc64le GNU/Linux
>> geert@tulgpu505:~/src/julia$  
>> 
>> Any suggestions?
>> 
>> Thanks,
>> 
>> Geert
> 

Re: [julia-users] IBM Power port

[Viral Shah]

I have uploaded Julia-0.5 on Power8 binaries here. These are built with the 
latest openblas (that passes all julia tests) and hence there is no need to use 
ATLAS.

https://drive.google.com/open?id=0B0rXlkvSbIfhVWpZb2hqclBIVms

Would be great if people can try this out.

-viral



> On Aug 19, 2016, at 9:06 AM, Viral Shah  wrote:
> 
> I am getting successful builds on the OSU Power8 machine. Once openblas has a 
> new release, I suspect we can provide pre-packaged power8 binaries. 
> 
> I am building on CentOS 7 and this is what lscpu says:
> 
> Architecture:  ppc64le
> Byte Order:Little Endian
> CPU(s):160
> On-line CPU(s) list:   0-159
> Thread(s) per core:8
> Core(s) per socket:10
> Socket(s): 2
> NUMA node(s):  2
> Model: 8335-GCA
> L1d cache: 64K
> L1i cache: 32K
> L2 cache:  512K
> L3 cache:  8192K
> NUMA node0 CPU(s): 0-79
> NUMA node8 CPU(s): 80-159
> 
> I suspect you are running into a codegen issue. Let’s give it a few days and 
> once llvm 3.9 releases, we can try that. If not, we may need Jameson’s help.
> 
> -viral
> 
> 
> 
>> On Aug 19, 2016, at 8:54 AM, Viral Shah  wrote:
>> 
>> It is hard to say what is happening there. Trying it out.
>> 
>> OpenBLAS develop branch is now passing on Power and hence Atlas should no 
>> longer be required. Note that you need the latest (3.10.4?) ATLAS, but in 
>> any case, this should not affect the build.
>> 
>> -viral
>> 
>> 
>> 
>>> On Aug 18, 2016, at 7:03 PM, Geert Janssen  wrote:
>>> 
>>> Dear Viral,
>>> 
>>> I am building Julie release-0.5 on a Power8E Ubuntu 14.10 machine.
>>> I use the following Make.user after having had trouble compiling OpenBLAS 
>>> that was pulled in:
>>> 
>>> created Make.user:
>>> override USE_SYSTEM_BLAS = 1
>>> override USE_BLAS64 = 0
>>> override LIBBLAS = -L/opt/atlas/lib -ltatlas
>>> override LIBBLASNAME = libtatlas
>>> 
>>> I get a clean build all the way till the end and then this happens:
>>> 
>>>   
>>>   JULIA usr/lib/julia/inference.ji
>>> /bin/sh: line 1:  6967 Segmentation fault  
>>> /localhome/geert/src/julia/usr/bin/julia -C native --output-ji 
>>> /localhome/geert/src/julia/usr/lib/julia/inference.ji --startup-file=no 
>>> coreimg.jl
>>> Makefile:215: recipe for target 
>>> '/localhome/geert/src/julia/usr/lib/julia/inference.ji' failed
>>> make[1]: *** [/localhome/geert/src/julia/usr/lib/julia/inference.ji] Error 
>>> 139
>>> Makefile:96: recipe for target 'julia-inference' failed
>>> make: *** [julia-inference] Error 2 
>>> 
>>> The machine and OS details are:
>>> 
>>> geert@tulgpu505:~/src/julia$ lscpu
>>> Architecture:  ppc64le
>>> Byte Order:Little Endian
>>> CPU(s):184
>>> On-line CPU(s) list:   0-151,160-191
>>> Thread(s) per core:8
>>> Core(s) per socket:5
>>> Socket(s): 4
>>> NUMA node(s):  4
>>> Model: 8247-42L
>>> CPU max MHz:   3923.
>>> CPU min MHz:   2061.
>>> L1d cache: 64K
>>> L1i cache: 32K
>>> L2 cache:  512K
>>> L3 cache:  8192K
>>> NUMA node0 CPU(s): 0-47
>>> NUMA node1 CPU(s): 48-95
>>> NUMA node16 CPU(s):96-143
>>> NUMA node17 CPU(s):144-151,160-191
>>> geert@tulgpu505:~/src/julia$ cat /etc/os-release 
>>> NAME="Ubuntu"
>>> VERSION="14.10 (Utopic Unicorn)"
>>> ID=ubuntu
>>> ID_LIKE=debian
>>> PRETTY_NAME="Ubuntu 14.10"
>>> VERSION_ID="14.10"
>>> HOME_URL="http://www.ubuntu.com/";
>>> SUPPORT_URL="http://help.ubuntu.com/";
>>> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/";
>>> geert@tulgpu505:~/src/julia$ uname -a
>>> Linux tulgpu505 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 UTC 
>>> 2015 ppc64le ppc64le ppc64le GNU/Linux
>>> geert@tulgpu505:~/src/julia$  
>>> 
>>> Any suggestions?
>>> 
>>> Thanks,
>>> 
>>> Geert
>> 
> 

Re: [julia-users] IBM Power port

[Patrick Kofod Mogensen]

Since this isn't Github I cannot :+1:, but great stuff!

On Friday, August 19, 2016 at 6:56:38 AM UTC+2, Viral Shah wrote:
>
> I have uploaded Julia-0.5 on Power8 binaries here. These are built with 
> the latest openblas (that passes all julia tests) and hence there is no 
> need to use ATLAS. 
>
> https://drive.google.com/open?id=0B0rXlkvSbIfhVWpZb2hqclBIVms 
>
> Would be great if people can try this out. 
>
> -viral 
>
>
>
> > On Aug 19, 2016, at 9:06 AM, Viral Shah > 
> wrote: 
> > 
> > I am getting successful builds on the OSU Power8 machine. Once openblas 
> has a new release, I suspect we can provide pre-packaged power8 binaries. 
> > 
> > I am building on CentOS 7 and this is what lscpu says: 
> > 
> > Architecture:  ppc64le 
> > Byte Order:Little Endian 
> > CPU(s):160 
> > On-line CPU(s) list:   0-159 
> > Thread(s) per core:8 
> > Core(s) per socket:10 
> > Socket(s): 2 
> > NUMA node(s):  2 
> > Model: 8335-GCA 
> > L1d cache: 64K 
> > L1i cache: 32K 
> > L2 cache:  512K 
> > L3 cache:  8192K 
> > NUMA node0 CPU(s): 0-79 
> > NUMA node8 CPU(s): 80-159 
> > 
> > I suspect you are running into a codegen issue. Let’s give it a few days 
> and once llvm 3.9 releases, we can try that. If not, we may need Jameson’s 
> help. 
> > 
> > -viral 
> > 
> > 
> > 
> >> On Aug 19, 2016, at 8:54 AM, Viral Shah > 
> wrote: 
> >> 
> >> It is hard to say what is happening there. Trying it out. 
> >> 
> >> OpenBLAS develop branch is now passing on Power and hence Atlas should 
> no longer be required. Note that you need the latest (3.10.4?) ATLAS, but 
> in any case, this should not affect the build. 
> >> 
> >> -viral 
> >> 
> >> 
> >> 
> >>> On Aug 18, 2016, at 7:03 PM, Geert Janssen  > wrote: 
> >>> 
> >>> Dear Viral, 
> >>> 
> >>> I am building Julie release-0.5 on a Power8E Ubuntu 14.10 machine. 
> >>> I use the following Make.user after having had trouble compiling 
> OpenBLAS that was pulled in: 
> >>> 
> >>> created Make.user: 
> >>> override USE_SYSTEM_BLAS = 1 
> >>> override USE_BLAS64 = 0 
> >>> override LIBBLAS = -L/opt/atlas/lib -ltatlas 
> >>> override LIBBLASNAME = libtatlas 
> >>> 
> >>> I get a clean build all the way till the end and then this happens: 
> >>> 
> >>>    
> >>>   JULIA usr/lib/julia/inference.ji 
> >>> /bin/sh: line 1:  6967 Segmentation fault 
>  /localhome/geert/src/julia/usr/bin/julia -C native --output-ji 
> /localhome/geert/src/julia/usr/lib/julia/inference.ji --startup-file=no 
> coreimg.jl 
> >>> Makefile:215: recipe for target 
> '/localhome/geert/src/julia/usr/lib/julia/inference.ji' failed 
> >>> make[1]: *** [/localhome/geert/src/julia/usr/lib/julia/inference.ji] 
> Error 139 
> >>> Makefile:96: recipe for target 'julia-inference' failed 
> >>> make: *** [julia-inference] Error 2 
> >>> 
> >>> The machine and OS details are: 
> >>> 
> >>> geert@tulgpu505:~/src/julia$ lscpu 
> >>> Architecture:  ppc64le 
> >>> Byte Order:Little Endian 
> >>> CPU(s):184 
> >>> On-line CPU(s) list:   0-151,160-191 
> >>> Thread(s) per core:8 
> >>> Core(s) per socket:5 
> >>> Socket(s): 4 
> >>> NUMA node(s):  4 
> >>> Model: 8247-42L 
> >>> CPU max MHz:   3923. 
> >>> CPU min MHz:   2061. 
> >>> L1d cache: 64K 
> >>> L1i cache: 32K 
> >>> L2 cache:  512K 
> >>> L3 cache:  8192K 
> >>> NUMA node0 CPU(s): 0-47 
> >>> NUMA node1 CPU(s): 48-95 
> >>> NUMA node16 CPU(s):96-143 
> >>> NUMA node17 CPU(s):144-151,160-191 
> >>> geert@tulgpu505:~/src/julia$ cat /etc/os-release 
> >>> NAME="Ubuntu" 
> >>> VERSION="14.10 (Utopic Unicorn)" 
> >>> ID=ubuntu 
> >>> ID_LIKE=debian 
> >>> PRETTY_NAME="Ubuntu 14.10" 
> >>> VERSION_ID="14.10" 
> >>> HOME_URL="http://www.ubuntu.com/"; 
> >>> SUPPORT_URL="http://help.ubuntu.com/"; 
> >>> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"; 
> >>> geert@tulgpu505:~/src/julia$ uname -a 
> >>> Linux tulgpu505 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 
> UTC 2015 ppc64le ppc64le ppc64le GNU/Linux 
> >>> geert@tulgpu505:~/src/julia$   
> >>> 
> >>> Any suggestions? 
> >>> 
> >>> Thanks, 
> >>> 
> >>> Geert 
> >> 
> > 
>
>

Re: [julia-users] IBM Power port

[Viral Shah]

We are getting this onto our buildbots thanks to Elliot and Tony. It would 
be great if folks can give these binaries a try.

https://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/0.5/julia-0.5.0-3005940a21-linuxppc64.tar.gz

Do run Base.runtests(). The processor warning is known, and report further 
issues here (and we can open new issues if they turn out to be new):

https://github.com/JuliaLang/julia/pull/18258

-viral

On Friday, August 19, 2016 at 10:26:38 AM UTC+5:30, Viral Shah wrote:
>
> I have uploaded Julia-0.5 on Power8 binaries here. These are built with 
> the latest openblas (that passes all julia tests) and hence there is no 
> need to use ATLAS. 
>
> https://drive.google.com/open?id=0B0rXlkvSbIfhVWpZb2hqclBIVms 
>
> Would be great if people can try this out. 
>
> -viral 
>
>
>
> > On Aug 19, 2016, at 9:06 AM, Viral Shah  wrote: 
> > 
> > I am getting successful builds on the OSU Power8 machine. Once openblas 
> has a new release, I suspect we can provide pre-packaged power8 binaries. 
> > 
> > I am building on CentOS 7 and this is what lscpu says: 
> > 
> > Architecture:  ppc64le 
> > Byte Order:Little Endian 
> > CPU(s):160 
> > On-line CPU(s) list:   0-159 
> > Thread(s) per core:8 
> > Core(s) per socket:10 
> > Socket(s): 2 
> > NUMA node(s):  2 
> > Model: 8335-GCA 
> > L1d cache: 64K 
> > L1i cache: 32K 
> > L2 cache:  512K 
> > L3 cache:  8192K 
> > NUMA node0 CPU(s): 0-79 
> > NUMA node8 CPU(s): 80-159 
> > 
> > I suspect you are running into a codegen issue. Let’s give it a few days 
> and once llvm 3.9 releases, we can try that. If not, we may need Jameson’s 
> help. 
> > 
> > -viral 
> > 
> > 
> > 
> >> On Aug 19, 2016, at 8:54 AM, Viral Shah  wrote: 
> >> 
> >> It is hard to say what is happening there. Trying it out. 
> >> 
> >> OpenBLAS develop branch is now passing on Power and hence Atlas should 
> no longer be required. Note that you need the latest (3.10.4?) ATLAS, but 
> in any case, this should not affect the build. 
> >> 
> >> -viral 
> >> 
> >> 
> >> 
> >>> On Aug 18, 2016, at 7:03 PM, Geert Janssen  wrote: 
> >>> 
> >>> Dear Viral, 
> >>> 
> >>> I am building Julie release-0.5 on a Power8E Ubuntu 14.10 machine. 
> >>> I use the following Make.user after having had trouble compiling 
> OpenBLAS that was pulled in: 
> >>> 
> >>> created Make.user: 
> >>> override USE_SYSTEM_BLAS = 1 
> >>> override USE_BLAS64 = 0 
> >>> override LIBBLAS = -L/opt/atlas/lib -ltatlas 
> >>> override LIBBLASNAME = libtatlas 
> >>> 
> >>> I get a clean build all the way till the end and then this happens: 
> >>> 
> >>>    
> >>>   JULIA usr/lib/julia/inference.ji 
> >>> /bin/sh: line 1:  6967 Segmentation fault 
>  /localhome/geert/src/julia/usr/bin/julia -C native --output-ji 
> /localhome/geert/src/julia/usr/lib/julia/inference.ji --startup-file=no 
> coreimg.jl 
> >>> Makefile:215: recipe for target 
> '/localhome/geert/src/julia/usr/lib/julia/inference.ji' failed 
> >>> make[1]: *** [/localhome/geert/src/julia/usr/lib/julia/inference.ji] 
> Error 139 
> >>> Makefile:96: recipe for target 'julia-inference' failed 
> >>> make: *** [julia-inference] Error 2 
> >>> 
> >>> The machine and OS details are: 
> >>> 
> >>> geert@tulgpu505:~/src/julia$ lscpu 
> >>> Architecture:  ppc64le 
> >>> Byte Order:Little Endian 
> >>> CPU(s):184 
> >>> On-line CPU(s) list:   0-151,160-191 
> >>> Thread(s) per core:8 
> >>> Core(s) per socket:5 
> >>> Socket(s): 4 
> >>> NUMA node(s):  4 
> >>> Model: 8247-42L 
> >>> CPU max MHz:   3923. 
> >>> CPU min MHz:   2061. 
> >>> L1d cache: 64K 
> >>> L1i cache: 32K 
> >>> L2 cache:  512K 
> >>> L3 cache:  8192K 
> >>> NUMA node0 CPU(s): 0-47 
> >>> NUMA node1 CPU(s): 48-95 
> >>> NUMA node16 CPU(s):96-143 
> >>> NUMA node17 CPU(s):144-151,160-191 
> >>> geert@tulgpu505:~/src/julia$ cat /etc/os-release 
> >>> NAME="Ubuntu" 
> >>> VERSION="14.10 (Utopic Unicorn)" 
> >>> ID=ubuntu 
> >>> ID_LIKE=debian 
> >>> PRETTY_NAME="Ubuntu 14.10" 
> >>> VERSION_ID="14.10" 
> >>> HOME_URL="http://www.ubuntu.com/"; 
> >>> SUPPORT_URL="http://help.ubuntu.com/"; 
> >>> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"; 
> >>> geert@tulgpu505:~/src/julia$ uname -a 
> >>> Linux tulgpu505 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 
> UTC 2015 ppc64le ppc64le ppc64le GNU/Linux 
> >>> geert@tulgpu505:~/src/julia$   
> >>> 
> >>> Any suggestions? 
> >>> 
> >>> Thanks, 
> >>> 
> >>> Geert 
> >> 
> > 
>
>

Re: [julia-users] IBM Power port

[Viral Shah]

I should point out that the linalg tests are expected to fail for now, 
since we are awaiting a new openblas release, which is known to fix these 
issues.

-viral

On Friday, August 19, 2016 at 10:26:38 AM UTC+5:30, Viral Shah wrote:
>
> I have uploaded Julia-0.5 on Power8 binaries here. These are built with 
> the latest openblas (that passes all julia tests) and hence there is no 
> need to use ATLAS. 
>
> https://drive.google.com/open?id=0B0rXlkvSbIfhVWpZb2hqclBIVms 
>
> Would be great if people can try this out. 
>
> -viral 
>
>
>
> > On Aug 19, 2016, at 9:06 AM, Viral Shah  wrote: 
> > 
> > I am getting successful builds on the OSU Power8 machine. Once openblas 
> has a new release, I suspect we can provide pre-packaged power8 binaries. 
> > 
> > I am building on CentOS 7 and this is what lscpu says: 
> > 
> > Architecture:  ppc64le 
> > Byte Order:Little Endian 
> > CPU(s):160 
> > On-line CPU(s) list:   0-159 
> > Thread(s) per core:8 
> > Core(s) per socket:10 
> > Socket(s): 2 
> > NUMA node(s):  2 
> > Model: 8335-GCA 
> > L1d cache: 64K 
> > L1i cache: 32K 
> > L2 cache:  512K 
> > L3 cache:  8192K 
> > NUMA node0 CPU(s): 0-79 
> > NUMA node8 CPU(s): 80-159 
> > 
> > I suspect you are running into a codegen issue. Let’s give it a few days 
> and once llvm 3.9 releases, we can try that. If not, we may need Jameson’s 
> help. 
> > 
> > -viral 
> > 
> > 
> > 
> >> On Aug 19, 2016, at 8:54 AM, Viral Shah  wrote: 
> >> 
> >> It is hard to say what is happening there. Trying it out. 
> >> 
> >> OpenBLAS develop branch is now passing on Power and hence Atlas should 
> no longer be required. Note that you need the latest (3.10.4?) ATLAS, but 
> in any case, this should not affect the build. 
> >> 
> >> -viral 
> >> 
> >> 
> >> 
> >>> On Aug 18, 2016, at 7:03 PM, Geert Janssen  wrote: 
> >>> 
> >>> Dear Viral, 
> >>> 
> >>> I am building Julie release-0.5 on a Power8E Ubuntu 14.10 machine. 
> >>> I use the following Make.user after having had trouble compiling 
> OpenBLAS that was pulled in: 
> >>> 
> >>> created Make.user: 
> >>> override USE_SYSTEM_BLAS = 1 
> >>> override USE_BLAS64 = 0 
> >>> override LIBBLAS = -L/opt/atlas/lib -ltatlas 
> >>> override LIBBLASNAME = libtatlas 
> >>> 
> >>> I get a clean build all the way till the end and then this happens: 
> >>> 
> >>>    
> >>>   JULIA usr/lib/julia/inference.ji 
> >>> /bin/sh: line 1:  6967 Segmentation fault 
>  /localhome/geert/src/julia/usr/bin/julia -C native --output-ji 
> /localhome/geert/src/julia/usr/lib/julia/inference.ji --startup-file=no 
> coreimg.jl 
> >>> Makefile:215: recipe for target 
> '/localhome/geert/src/julia/usr/lib/julia/inference.ji' failed 
> >>> make[1]: *** [/localhome/geert/src/julia/usr/lib/julia/inference.ji] 
> Error 139 
> >>> Makefile:96: recipe for target 'julia-inference' failed 
> >>> make: *** [julia-inference] Error 2 
> >>> 
> >>> The machine and OS details are: 
> >>> 
> >>> geert@tulgpu505:~/src/julia$ lscpu 
> >>> Architecture:  ppc64le 
> >>> Byte Order:Little Endian 
> >>> CPU(s):184 
> >>> On-line CPU(s) list:   0-151,160-191 
> >>> Thread(s) per core:8 
> >>> Core(s) per socket:5 
> >>> Socket(s): 4 
> >>> NUMA node(s):  4 
> >>> Model: 8247-42L 
> >>> CPU max MHz:   3923. 
> >>> CPU min MHz:   2061. 
> >>> L1d cache: 64K 
> >>> L1i cache: 32K 
> >>> L2 cache:  512K 
> >>> L3 cache:  8192K 
> >>> NUMA node0 CPU(s): 0-47 
> >>> NUMA node1 CPU(s): 48-95 
> >>> NUMA node16 CPU(s):96-143 
> >>> NUMA node17 CPU(s):144-151,160-191 
> >>> geert@tulgpu505:~/src/julia$ cat /etc/os-release 
> >>> NAME="Ubuntu" 
> >>> VERSION="14.10 (Utopic Unicorn)" 
> >>> ID=ubuntu 
> >>> ID_LIKE=debian 
> >>> PRETTY_NAME="Ubuntu 14.10" 
> >>> VERSION_ID="14.10" 
> >>> HOME_URL="http://www.ubuntu.com/"; 
> >>> SUPPORT_URL="http://help.ubuntu.com/"; 
> >>> BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"; 
> >>> geert@tulgpu505:~/src/julia$ uname -a 
> >>> Linux tulgpu505 3.16.0-30-generic #40-Ubuntu SMP Mon Jan 12 22:07:11 
> UTC 2015 ppc64le ppc64le ppc64le GNU/Linux 
> >>> geert@tulgpu505:~/src/julia$   
> >>> 
> >>> Any suggestions? 
> >>> 
> >>> Thanks, 
> >>> 
> >>> Geert 
> >> 
> > 
>
>

Re: [julia-users] IBM Power port

[James Fairbanks]

Hi Viral, 

I got negative results on my power8 machine. 
After untarring the link above I got the following errors when just running 
the repl.


[jpf@power8 julia-3005940a21]$ ./bin/julia 
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
'powerpc64le' is not a recognized processor for this target (ignoring 
processor)
   _
   _   _ _(_)_ |  A fresh approach to technical computing
  (_) | (_) (_)|  Documentation: http://docs.julialang.org
   _ _   _| |_  __ _   |  Type "?help" for help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 0.5.0-rc3+3 (2016-08-26 06:19 UTC)
 _/ |\__'_|_|_|\__'_|  |  sf/ppc64le/3005940 (fork: 3 commits, 9 days)
|__/   |  powerpc64le-unknown-linux-gnu


Then I got a lot more errors. 
For example: 

WARNING: Method definition f(Tuple{Vararg{Int64, #N<:Any}}, 
AbstractArray{#T<:Any, #N<:Any}) in module Main at 
/home/jpf/julia-3005940a21/share/julia/test/core.jl:706 overwritten at 
/home/jpf/julia-3005940a21/share/julia/test/core.jl:712.
From worker 13: * linalg/diagonal   in 101.62 seconds, 
maxrss  348.31 MB
From worker 13: * inference in   0.92 seconds, 
maxrss  352.38 MB
From worker 13: * keywordargs   in   1.56 seconds, 
maxrss  354.13 MB
WARNING: Method definition f() in module JLCall14301 at 
/home/jpf/julia-3005940a21/share/julia/test/core.jl:3529 overwritten at 
/home/jpf/julia-3005940a21/share/julia/test/core.jl:3539.
From worker 5: * linalg/matmul in 169.17 seconds, 
maxrss  367.69 MB
From worker 16: * linalg/cholesky   in  96.71 seconds, 
maxrss  332.44 MB
From worker 16: * char Error During Test
From worker 16:  Test threw an exception of type InexactError
From worker 16:  Expression: $(Expr(:escape, 
:(convert(Char,Float16(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
:(convert(Char,Float32(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
:(convert(Char,Float64(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
:(Char(x
From worker 16:  InexactError()
From worker 16:   in macro expansion; at 
/home/jpf/julia-3005940a21/share/julia/test/char.jl:72 [inlined]
From worker 16:   in anonymous at ./:?
From worker 16:   in include_string(::String, ::String) at 
./loading.jl:380
From worker 16:   in include_from_node1(::String) at 
./loading.jl:429
From worker 16:   in macro expansion at ./util.jl:226 [inlined]
From worker 16:   in runtests(::String) at 
/home/jpf/julia-3005940a21/share/julia/test/testdefs.jl:7
From worker 16:   in 
(::Base.Serializer.__deserialized_types__.##16#24)(::String) at 
/home/jpf/julia-3005940a21/share/julia/test/runtests.jl:44
From worker 16:   in 
(::Base.##625#627{Base.CallMsg{:call_fetch}})() at ./multi.jl:1421
From worker 16:   in 
run_work_thunk(::Base.##625#627{Base.CallMsg{:call_fetch}}, ::Bool) at 
./multi.jl:1001
From worker 16:   in macro expansion at ./multi.jl:1421 [inlined]
From worker 16:   in 
(::Base.##624#626{Base.CallMsg{:call_fetch},Base.MsgHeader,TCPSocket})() at 
./event.jl:68

On Tuesday, August 30, 2016 at 1:30:54 AM UTC-4, Viral Shah wrote:
>
> I should point out that the linalg tests are expected to fail for now, 
> since we are awaiting a new openblas release, which is known to fix these 
> issues.
>
> -viral
>
> On Friday, August 19, 2016 at 10:26:38 AM UTC+5:30, Viral Shah wrote:
>>
>> I have uploaded Julia-0.5 on Power8 binaries here. These are built with 
>> the latest openblas (that passes all julia tests) and hence there is no 
>> need to use ATLAS. 
>>
>> https://drive.google.com/open?id=0B0rXlkvSbIfhVWpZb2hqclBIVms 
>>
>> Would be great if people can try this out. 
>>
>> -viral 
>>
>>
>>
>> > On Aug 19, 2016, at 9:06 AM, Viral Shah > 
>> wrote: 
>> > 
>> > I am getting successful builds on the OSU Power8 machine. Once openblas 
>> has a new release, I suspect we can provide pre-packaged power8 binaries. 
>> > 
>> > I am building on CentOS 7 and this is what lscpu says: 
>> > 
>> > Architectur

Re: [julia-users] IBM Power port

[Viral Shah]

Can you try this one? I believe this error is addressed now.

http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/julia-latest-linuxppc64.tar.gz

Also, Elliot enabled the nightlies: 

https://build.julialang.org/builders/package_tarballppc64le

-viral


> On Sep 2, 2016, at 4:15 AM, James Fairbanks  wrote:
> 
> Hi Viral, 
> 
> I got negative results on my power8 machine. 
> After untarring the link above I got the following errors when just running 
> the repl.
> 
> 
> [jpf@power8 julia-3005940a21]$ ./bin/julia 
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
> 'powerpc64le' is not a recognized processor for this target (ignoring 
> processor)
>_
>_   _ _(_)_ |  A fresh approach to technical computing
>   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>_ _   _| |_  __ _   |  Type "?help" for help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 0.5.0-rc3+3 (2016-08-26 06:19 UTC)
>  _/ |\__'_|_|_|\__'_|  |  sf/ppc64le/3005940 (fork: 3 commits, 9 days)
> |__/   |  powerpc64le-unknown-linux-gnu
> 
> 
> Then I got a lot more errors. 
> For example: 
> 
> WARNING: Method definition f(Tuple{Vararg{Int64, #N<:Any}}, 
> AbstractArray{#T<:Any, #N<:Any}) in module Main at 
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:706 overwritten at 
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:712.
> From worker 13: * linalg/diagonal   in 101.62 seconds, maxrss 
>  348.31 MB
> From worker 13: * inference in   0.92 seconds, maxrss 
>  352.38 MB
> From worker 13: * keywordargs   in   1.56 seconds, maxrss 
>  354.13 MB
> WARNING: Method definition f() in module JLCall14301 at 
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:3529 overwritten at 
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:3539.
> From worker 5: * linalg/matmul in 169.17 seconds, maxrss  
> 367.69 MB
> From worker 16: * linalg/cholesky   in  96.71 seconds, maxrss 
>  332.44 MB
> From worker 16: * char Error During Test
> From worker 16:  Test threw an exception of type InexactError
> From worker 16:  Expression: $(Expr(:escape, 
> :(convert(Char,Float16(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
> :(convert(Char,Float32(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
> :(convert(Char,Float64(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
> :(Char(x
> From worker 16:  InexactError()
> From worker 16:   in macro expansion; at 
> /home/jpf/julia-3005940a21/share/julia/test/char.jl:72 [inlined]
> From worker 16:   in anonymous at ./:?
> From worker 16:   in include_string(::String, ::String) at 
> ./loading.jl:380
> From worker 16:   in include_from_node1(::String) at ./loading.jl:429
> From worker 16:   in macro expansion at ./util.jl:226 [inlined]
> From worker 16:   in runtests(::String) at 
> /home/jpf/julia-3005940a21/share/julia/test/testdefs.jl:7
> From worker 16:   in 
> (::Base.Serializer.__deserialized_types__.##16#24)(::String) at 
> /home/jpf/julia-3005940a21/share/julia/test/runtests.jl:44
> From worker 16:   in (::Base.##625#627{Base.CallMsg{:call_fetch}})() 
> at ./multi.jl:1421
> From worker 16:   in 
> run_work_thunk(::Base.##625#627{Base.CallMsg{:call_fetch}}, ::Bool) at 
> ./multi.jl:1001
> From worker 16:   in macro expansion at ./multi.jl:1421 [inlined]
> From worker 16:   in 
> (::Base.##624#626{Base.CallMsg{:call_fetch},Base.MsgHeader,TCPSocket})() at 
> ./event.jl:68
> 
> On Tuesday, August 30, 2016 at 1:30:54 AM UTC-4, Viral Shah wrote:
> I should point out that the linalg tests are expected to fail for now, since 
> we are awaiting a new openblas release, which is known to fix these issues.
> 
> -viral
> 
> On Friday, August 19, 2016 at 10:26:38 AM UTC+5:30, Viral Shah wrote:
> I have uploaded Julia-0.5 on Power8 binaries here. These are built with the 
> latest openblas (that passes all julia tests) and h

Re: [julia-users] IBM Power port

[Paulito Palmes]

Hi All,

I noticed that some of the packages are not aware that Julia has power port
now and when you install those packages, they include some compiler
directives specific to Intel processor such as SSE. In the Makefile, I
removed this extra option and the package compiles. However, if I do
Pkg.build("Package"), it does not respect the edited Makefile and starts to
download from github. I don't know the sequence of operations behind but is
there a way to manually compile and install the local package downloaded
after you edit some files to make it work for the power machine?

I think the long term solution is to have a test server running power
machine to flag that the package did not compile successfully to the power
port.

-paulito

On Fri, Sep 2, 2016 at 8:02 AM, Viral Shah  wrote:

> Can you try this one? I believe this error is addressed now.
>
> http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/julia-latest-
> linuxppc64.tar.gz
>
> Also, Elliot enabled the nightlies:
>
> https://build.julialang.org/builders/package_tarballppc64le
>
> -viral
>
>
> > On Sep 2, 2016, at 4:15 AM, James Fairbanks 
> wrote:
> >
> > Hi Viral,
> >
> > I got negative results on my power8 machine.
> > After untarring the link above I got the following errors when just
> running the repl.
> >
> >
> > [jpf@power8 julia-3005940a21]$ ./bin/julia
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> > 'powerpc64le' is not a recognized processor for this target (ignoring
> processor)
> >_
> >_   _ _(_)_ |  A fresh approach to technical computing
> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
> >_ _   _| |_  __ _   |  Type "?help" for help.
> >   | | | | | | |/ _` |  |
> >   | | |_| | | | (_| |  |  Version 0.5.0-rc3+3 (2016-08-26 06:19 UTC)
> >  _/ |\__'_|_|_|\__'_|  |  sf/ppc64le/3005940 (fork: 3 commits, 9 days)
> > |__/   |  powerpc64le-unknown-linux-gnu
> >
> >
> > Then I got a lot more errors.
> > For example:
> >
> > WARNING: Method definition f(Tuple{Vararg{Int64, #N<:Any}},
> AbstractArray{#T<:Any, #N<:Any}) in module Main at
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:706 overwritten at
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:712.
> > From worker 13: * linalg/diagonal   in 101.62 seconds,
> maxrss  348.31 MB
> > From worker 13: * inference in   0.92 seconds,
> maxrss  352.38 MB
> > From worker 13: * keywordargs   in   1.56 seconds,
> maxrss  354.13 MB
> > WARNING: Method definition f() in module JLCall14301 at
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:3529 overwritten at
> /home/jpf/julia-3005940a21/share/julia/test/core.jl:3539.
> > From worker 5: * linalg/matmul in 169.17 seconds,
> maxrss  367.69 MB
> > From worker 16: * linalg/cholesky   in  96.71 seconds,
> maxrss  332.44 MB
> > From worker 16: * char Error During Test
> > From worker 16:  Test threw an exception of type InexactError
> > From worker 16:  Expression: $(Expr(:escape,
> :(convert(Char,Float16(x) $(Expr(:escape, :(==))) $(Expr(:escape,
> :(convert(Char,Float32(x) $(Expr(:escape, :(==))) $(Expr(:escape,
> :(convert(Char,Float64(x) $(Expr(:escape, :(==))) $(Expr(:escape,
> :(Char(x
> > From worker 16:  InexactError()
> > From worker 16:   in macro expansion; at
> /home/jpf/julia-3005940a21/share/julia/test/char.jl:72 [inlined]
> > From worker 16:   in anonymous at ./:?
> > From worker 16:   in include_string(::String, ::String) at
> ./loading.jl:380
> > From worker 16:   in include_from_node1(::String) at
> ./loading.jl:429
> > From worker 16:   in macro expansion at ./util.jl:226 [inlined]
> > From worker 16:   in runtests(::String) at
> /home/jpf/julia-3005940a21/share/julia/test/testdefs.jl:7
> > From worker 16:   in (::Base.Serializer.__
> deserialized_types__.##16#24)(::String) at /home/jpf/julia-3005940a21/
> share/julia/test/runtests.j

Re: [julia-users] IBM Power port

[Paulito Palmes]

I also noticed (not specific to Power machines) that when you want to load
packages in Julia with several workers, I have to do the following to have
successful loading of packages:

nprocs()==1 && addprocs()
using Knet
@everywhere using Knet
using RDatasets
@everywhere using RDatasets
using MLBase
@everywhere using MLBase


If I use,
nprocs()==1 && addprocs()
@everywhere using RDatasets
@everywhere using Knet
@everywhere using MLBase

I have this error:
ERROR: On worker 2:
LoadError: LoadError: UndefVarError: @knet not defined

If I use,
nprocs()==1 && addprocs()
using RDatasets
using Knet
using MLBase

ERROR (unhandled task failure): On worker 4:
On worker 4:
On worker 4:
UndefVarError: Gaussian not defined

Attached is the code that I use which uses 3 @parallel for syntax

My insight is that you need to load first all the packages into the process
id 1 to avoid clashes during pre-cache compilation and use @everywhere
using
to export the functions to other processes. It seems that just *using*
directives does not immediately export those functions to all processes
based on the code attached such that I have to use "@everywhere using"
directives. Is this a bug?

Please try to reproduce the errors I have with the attached code. This
error only happens if you do addprocs() to run parallel julia.

I'm using Julia 0.4.6 (2016-06-19 17:16 UTC)

On Fri, Sep 2, 2016 at 9:52 AM, Paulito Palmes  wrote:

> Hi All,
>
> I noticed that some of the packages are not aware that Julia has power
> port now and when you install those packages, they include some compiler
> directives specific to Intel processor such as SSE. In the Makefile, I
> removed this extra option and the package compiles. However, if I do
> Pkg.build("Package"), it does not respect the edited Makefile and starts to
> download from github. I don't know the sequence of operations behind but is
> there a way to manually compile and install the local package downloaded
> after you edit some files to make it work for the power machine?
>
> I think the long term solution is to have a test server running power
> machine to flag that the package did not compile successfully to the power
> port.
>
> -paulito
>
> On Fri, Sep 2, 2016 at 8:02 AM, Viral Shah  wrote:
>
>> Can you try this one? I believe this error is addressed now.
>>
>> http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/
>> julia-latest-linuxppc64.tar.gz
>>
>> Also, Elliot enabled the nightlies:
>>
>> https://build.julialang.org/builders/package_tarballppc64le
>>
>> -viral
>>
>>
>> > On Sep 2, 2016, at 4:15 AM, James Fairbanks 
>> wrote:
>> >
>> > Hi Viral,
>> >
>> > I got negative results on my power8 machine.
>> > After untarring the link above I got the following errors when just
>> running the repl.
>> >
>> >
>> > [jpf@power8 julia-3005940a21]$ ./bin/julia
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring
>> processor)
>> >_
>> >_   _ _(_)_ |  A fresh approach to technical computing
>> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>> >_ _   _| |_  __ _   |  Type "?help" for help.
>> >   | | | | | | |/ _` |  |
>> >   | | |_| | | | (_| |  |  Version 0.5.0-rc3+3 (2016-08-26 06:19 UTC)
>> >  _/ |\__'_|_|_|\__'_|  |  sf/ppc64le/3005940 (fork: 3 commits, 9 days)
>> > |__/   |  powerpc64le-unknown-linux-gnu
>> >
>> >
>> > Then I got a lot more errors.
>> > For example:
>> >
>> > WARNING: Method definition f(Tuple{Vararg{Int64, #N<:Any}},
>> AbstractArray{#T<:Any, #N<:Any}) in module Main at
>> /home/jpf/julia-3005940a21/share/julia/test/core.jl:706 overwritten at
>> /home/jpf/julia-3005940a21/share/julia/test/core.jl:712.
>> > From worker 13: * linalg/diagonal   in 101.62 seconds,
>> maxrss  348.31 MB
>> > From worker 13: * inference in   0.92 seconds,
>> maxrss  352.38 MB
>> > From worker 13: * keywordargs   in   1.56 seconds,
>> maxrss  354.13 MB
>> > WARNING: Method definition f

Re: [julia-users] IBM Power port

[Viral Shah]

You do not need @everywhere. `using` will load on all nodes.

-viral

On Friday, September 2, 2016 at 2:39:34 PM UTC+5:30, Paulito Palmes wrote:
>
> I also noticed (not specific to Power machines) that when you want to load 
> packages in Julia with several workers, I have to do the following to have 
> successful loading of packages:
>
> nprocs()==1 && addprocs()
> using Knet
> @everywhere using Knet
> using RDatasets
> @everywhere using RDatasets
> using MLBase
> @everywhere using MLBase
>
>
> If I use, 
> nprocs()==1 && addprocs()
> @everywhere using RDatasets
> @everywhere using Knet
> @everywhere using MLBase
>
> I have this error:
> ERROR: On worker 2:
> LoadError: LoadError: UndefVarError: @knet not defined
>
> If I use,
> nprocs()==1 && addprocs()
> using RDatasets
> using Knet
> using MLBase
>
> ERROR (unhandled task failure): On worker 4:
> On worker 4:
> On worker 4:
> UndefVarError: Gaussian not defined
>
> Attached is the code that I use which uses 3 @parallel for syntax
>
> My insight is that you need to load first all the packages into the 
> process id 1 to avoid clashes during pre-cache compilation and use 
> @everywhere using 
> to export the functions to other processes. It seems that just *using* 
> directives does not immediately export those functions to all processes 
> based on the code attached such that I have to use "@everywhere using" 
> directives. Is this a bug?
>
> Please try to reproduce the errors I have with the attached code. This 
> error only happens if you do addprocs() to run parallel julia.
>
> I'm using Julia 0.4.6 (2016-06-19 17:16 UTC)
>
> On Fri, Sep 2, 2016 at 9:52 AM, Paulito Palmes  wrote:
>
>> Hi All,
>>
>> I noticed that some of the packages are not aware that Julia has power 
>> port now and when you install those packages, they include some compiler 
>> directives specific to Intel processor such as SSE. In the Makefile, I 
>> removed this extra option and the package compiles. However, if I do 
>> Pkg.build("Package"), it does not respect the edited Makefile and starts to 
>> download from github. I don't know the sequence of operations behind but is 
>> there a way to manually compile and install the local package downloaded 
>> after you edit some files to make it work for the power machine?
>>
>> I think the long term solution is to have a test server running power 
>> machine to flag that the package did not compile successfully to the power 
>> port.
>>
>> -paulito
>>
>> On Fri, Sep 2, 2016 at 8:02 AM, Viral Shah  wrote:
>>
>>> Can you try this one? I believe this error is addressed now.
>>>
>>>
>>> http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/julia-latest-linuxppc64.tar.gz
>>>
>>> Also, Elliot enabled the nightlies:
>>>
>>> https://build.julialang.org/builders/package_tarballppc64le
>>>
>>> -viral
>>>
>>>
>>> > On Sep 2, 2016, at 4:15 AM, James Fairbanks  
>>> wrote:
>>> >
>>> > Hi Viral,
>>> >
>>> > I got negative results on my power8 machine.
>>> > After untarring the link above I got the following errors when just 
>>> running the repl.
>>> >
>>> >
>>> > [jpf@power8 julia-3005940a21]$ ./bin/julia
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>>> processor)
>>> >_
>>> >_   _ _(_)_ |  A fresh approach to technical computing
>>> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>>> >_ _   _| |_  __ _   |  Type "?help" for help.
>>> >   | | | | | | |/ _` |  |
>>> >   | | |_| | | | (_| |  |  Version 0.5.0-rc3+3 (2016-08-26 06:19 UTC)
>>> >  _/ |\__'_|_|_|\__'_|  |  sf/ppc64le/3005940 (fork: 3 commits, 9 days)
>>> > |__/   |  powerpc64le-unknown-linux-gnu
>>> >
>>> >
>>> > Then I got a lot more errors.
>>> > For example:
>>> >
>>> > WARNING: Method definition f(Tuple{Vararg{Int64, #N<:Any}}, 
>>> AbstractArray{#T<:Any, #N<:Any}) in module Main at 
>>> /home/jpf/julia-3005940a21/share/julia/test/core.jl:706 overwritten at 
>>> /home/jpf/julia-3005940a21

Re: [julia-users] IBM Power port

[Viral Shah]

That is quite a lot of work. If there was support with Travis or some other 
CI provider, at least this would be easier and authors who want to support 
Power could then do so. 

-viral

On Friday, September 2, 2016 at 2:22:18 PM UTC+5:30, Paulito Palmes wrote:
>
> Hi All,
>
> I noticed that some of the packages are not aware that Julia has power 
> port now and when you install those packages, they include some compiler 
> directives specific to Intel processor such as SSE. In the Makefile, I 
> removed this extra option and the package compiles. However, if I do 
> Pkg.build("Package"), it does not respect the edited Makefile and starts to 
> download from github. I don't know the sequence of operations behind but is 
> there a way to manually compile and install the local package downloaded 
> after you edit some files to make it work for the power machine?
>
> I think the long term solution is to have a test server running power 
> machine to flag that the package did not compile successfully to the power 
> port.
>
> -paulito
>
> On Fri, Sep 2, 2016 at 8:02 AM, Viral Shah  wrote:
>
>> Can you try this one? I believe this error is addressed now.
>>
>>
>> http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/julia-latest-linuxppc64.tar.gz
>>
>> Also, Elliot enabled the nightlies:
>>
>> https://build.julialang.org/builders/package_tarballppc64le
>>
>> -viral
>>
>>
>> > On Sep 2, 2016, at 4:15 AM, James Fairbanks  
>> wrote:
>> >
>> > Hi Viral,
>> >
>> > I got negative results on my power8 machine.
>> > After untarring the link above I got the following errors when just 
>> running the repl.
>> >
>> >
>> > [jpf@power8 julia-3005940a21]$ ./bin/julia
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> > 'powerpc64le' is not a recognized processor for this target (ignoring 
>> processor)
>> >_
>> >_   _ _(_)_ |  A fresh approach to technical computing
>> >   (_) | (_) (_)|  Documentation: http://docs.julialang.org
>> >_ _   _| |_  __ _   |  Type "?help" for help.
>> >   | | | | | | |/ _` |  |
>> >   | | |_| | | | (_| |  |  Version 0.5.0-rc3+3 (2016-08-26 06:19 UTC)
>> >  _/ |\__'_|_|_|\__'_|  |  sf/ppc64le/3005940 (fork: 3 commits, 9 days)
>> > |__/   |  powerpc64le-unknown-linux-gnu
>> >
>> >
>> > Then I got a lot more errors.
>> > For example:
>> >
>> > WARNING: Method definition f(Tuple{Vararg{Int64, #N<:Any}}, 
>> AbstractArray{#T<:Any, #N<:Any}) in module Main at 
>> /home/jpf/julia-3005940a21/share/julia/test/core.jl:706 overwritten at 
>> /home/jpf/julia-3005940a21/share/julia/test/core.jl:712.
>> > From worker 13: * linalg/diagonal   in 101.62 seconds, 
>> maxrss  348.31 MB
>> > From worker 13: * inference in   0.92 seconds, 
>> maxrss  352.38 MB
>> > From worker 13: * keywordargs   in   1.56 seconds, 
>> maxrss  354.13 MB
>> > WARNING: Method definition f() in module JLCall14301 at 
>> /home/jpf/julia-3005940a21/share/julia/test/core.jl:3529 overwritten at 
>> /home/jpf/julia-3005940a21/share/julia/test/core.jl:3539.
>> > From worker 5: * linalg/matmul in 169.17 seconds, 
>> maxrss  367.69 MB
>> > From worker 16: * linalg/cholesky   in  96.71 seconds, 
>> maxrss  332.44 MB
>> > From worker 16: * char Error During Test
>> > From worker 16:  Test threw an exception of type InexactError
>> > From worker 16:  Expression: $(Expr(:escape, 
>> :(convert(Char,Float16(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
>> :(convert(Char,Float32(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
>> :(convert(Char,Float64(x) $(Expr(:escape, :(==))) $(Expr(:escape, 
>> :(Char(x
>> > From worker 16:  InexactError()
>> > From worker 16:   in macro expansion; at 
>> /home/jpf/julia-3005940a21/share/julia/test/char.jl:72 [inlined]
>> > From worker 16:   in anonymous at ./:?
>> > From worker 16:   in include_string(::String, ::String) at 
>> ./loading.jl:380
>> >   

Re: [julia-users] IBM Power port

[Paulito]

Hi Viral, 

That is what I thought and read in the docs but if you run the code I attached, 
merely 'using' would spit some errors where the workers are not aware of the 
existence of certain function. 

It can be in the name resolution or is it because the function is inside the a 
macro? I thin not a lot of packages are tested in using @parallel for. So far, 
the only solution so that my code work is to use using first and the 
@everywhere using.

Sent from my iPhone

> On 2 Sep 2016, at 17:29, Viral Shah  wrote:
> 
> You do not need @everywhere. `using` will load on all nodes.
> 
> -viral
> 
>> On Friday, September 2, 2016 at 2:39:34 PM UTC+5:30, Paulito Palmes wrote:
>> I also noticed (not specific to Power machines) that when you want to load 
>> packages in Julia with several workers, I have to do the following to have 
>> successful loading of packages:
>> 
>> nprocs()==1 && addprocs()
>> using Knet
>> @everywhere using Knet
>> using RDatasets
>> @everywhere using RDatasets
>> using MLBase
>> @everywhere using MLBase
>> 
>> 
>> If I use, 
>> nprocs()==1 && addprocs()
>> @everywhere using RDatasets
>> @everywhere using Knet
>> @everywhere using MLBase
>> 
>> I have this error:
>> ERROR: On worker 2:
>> LoadError: LoadError: UndefVarError: @knet not defined
>> 
>> If I use,
>> nprocs()==1 && addprocs()
>> using RDatasets
>> using Knet
>> using MLBase
>> 
>> ERROR (unhandled task failure): On worker 4:
>> On worker 4:
>> On worker 4:
>> UndefVarError: Gaussian not defined
>> 
>> Attached is the code that I use which uses 3 @parallel for syntax
>> 
>> My insight is that you need to load first all the packages into the process 
>> id 1 to avoid clashes during pre-cache compilation and use @everywhere using 
>> to export the functions to other processes. It seems that just *using* 
>> directives does not immediately export those functions to all processes 
>> based on the code attached such that I have to use "@everywhere using" 
>> directives. Is this a bug?
>> 
>> Please try to reproduce the errors I have with the attached code. This error 
>> only happens if you do addprocs() to run parallel julia.
>> 
>> I'm using Julia 0.4.6 (2016-06-19 17:16 UTC)
>> 
>>> On Fri, Sep 2, 2016 at 9:52 AM, Paulito Palmes  wrote:
>>> Hi All,
>>> 
>>> I noticed that some of the packages are not aware that Julia has power port 
>>> now and when you install those packages, they include some compiler 
>>> directives specific to Intel processor such as SSE. In the Makefile, I 
>>> removed this extra option and the package compiles. However, if I do 
>>> Pkg.build("Package"), it does not respect the edited Makefile and starts to 
>>> download from github. I don't know the sequence of operations behind but is 
>>> there a way to manually compile and install the local package downloaded 
>>> after you edit some files to make it work for the power machine?
>>> 
>>> I think the long term solution is to have a test server running power 
>>> machine to flag that the package did not compile successfully to the power 
>>> port.
>>> 
>>> -paulito
>>> 
 On Fri, Sep 2, 2016 at 8:02 AM, Viral Shah  wrote:
 Can you try this one? I believe this error is addressed now.
 
 http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/julia-latest-linuxppc64.tar.gz
 
 Also, Elliot enabled the nightlies:
 
 https://build.julialang.org/builders/package_tarballppc64le
 
 -viral
 
 
 > On Sep 2, 2016, at 4:15 AM, James Fairbanks  
 > wrote:
 >
 > Hi Viral,
 >
 > I got negative results on my power8 machine.
 > After untarring the link above I got the following errors when just 
 > running the repl.
 >
 >
 > [jpf@power8 julia-3005940a21]$ ./bin/julia
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 > processor)
 >_
 >_   _ _(_)_ |  A fresh approach to technica

Re: [julia-users] IBM Power port

[Viral Shah]

One more nightly on power:

http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/0.6/julia-0.6.0-5f91c39b1c-linuxppc64.tar.gz


With this PR being merged, I am hoping 0.5 will build fine on the powerpc 
buildbot, and that we should start getting regular nightlies (until something 
break).


https://github.com/JuliaLang/julia/pull/18418


-viral

On Friday, September 2, 2016 at 10:32:47 PM UTC+5:30, Paulito Palmes wrote:
>
> Hi Viral, 
>
> That is what I thought and read in the docs but if you run the code I 
> attached, merely 'using' would spit some errors where the workers are not 
> aware of the existence of certain function. 
>
> It can be in the name resolution or is it because the function is inside 
> the a macro? I thin not a lot of packages are tested in using @parallel 
> for. So far, the only solution so that my code work is to use using first 
> and the @everywhere using.
>
> Sent from my iPhone
>
> On 2 Sep 2016, at 17:29, Viral Shah  wrote:
>
> You do not need @everywhere. `using` will load on all nodes.
>
> -viral
>
> On Friday, September 2, 2016 at 2:39:34 PM UTC+5:30, Paulito Palmes wrote:
>>
>> I also noticed (not specific to Power machines) that when you want to 
>> load packages in Julia with several workers, I have to do the following to 
>> have successful loading of packages:
>>
>> nprocs()==1 && addprocs()
>> using Knet
>> @everywhere using Knet
>> using RDatasets
>> @everywhere using RDatasets
>> using MLBase
>> @everywhere using MLBase
>>
>>
>> If I use, 
>> nprocs()==1 && addprocs()
>> @everywhere using RDatasets
>> @everywhere using Knet
>> @everywhere using MLBase
>>
>> I have this error:
>> ERROR: On worker 2:
>> LoadError: LoadError: UndefVarError: @knet not defined
>>
>> If I use,
>> nprocs()==1 && addprocs()
>> using RDatasets
>> using Knet
>> using MLBase
>>
>> ERROR (unhandled task failure): On worker 4:
>> On worker 4:
>> On worker 4:
>> UndefVarError: Gaussian not defined
>>
>> Attached is the code that I use which uses 3 @parallel for syntax
>>
>> My insight is that you need to load first all the packages into the 
>> process id 1 to avoid clashes during pre-cache compilation and use 
>> @everywhere using 
>> to export the functions to other processes. It seems that just *using* 
>> directives does not immediately export those functions to all processes 
>> based on the code attached such that I have to use "@everywhere using" 
>> directives. Is this a bug?
>>
>> Please try to reproduce the errors I have with the attached code. This 
>> error only happens if you do addprocs() to run parallel julia.
>>
>> I'm using Julia 0.4.6 (2016-06-19 17:16 UTC)
>>
>> On Fri, Sep 2, 2016 at 9:52 AM, Paulito Palmes  wrote:
>>
>>> Hi All,
>>>
>>> I noticed that some of the packages are not aware that Julia has power 
>>> port now and when you install those packages, they include some compiler 
>>> directives specific to Intel processor such as SSE. In the Makefile, I 
>>> removed this extra option and the package compiles. However, if I do 
>>> Pkg.build("Package"), it does not respect the edited Makefile and starts to 
>>> download from github. I don't know the sequence of operations behind but is 
>>> there a way to manually compile and install the local package downloaded 
>>> after you edit some files to make it work for the power machine?
>>>
>>> I think the long term solution is to have a test server running power 
>>> machine to flag that the package did not compile successfully to the power 
>>> port.
>>>
>>> -paulito
>>>
>>> On Fri, Sep 2, 2016 at 8:02 AM, Viral Shah  wrote:
>>>
 Can you try this one? I believe this error is addressed now.


 http://s3.amazonaws.com/julianightlies/bin/linux/ppc64le/julia-latest-linuxppc64.tar.gz

 Also, Elliot enabled the nightlies:

 https://build.julialang.org/builders/package_tarballppc64le

 -viral


 > On Sep 2, 2016, at 4:15 AM, James Fairbanks  
 wrote:
 >
 > Hi Viral,
 >
 > I got negative results on my power8 machine.
 > After untarring the link above I got the following errors when just 
 running the repl.
 >
 >
 > [jpf@power8 julia-3005940a21]$ ./bin/julia
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized processor for this target (ignoring 
 processor)
 > 'powerpc64le' is not a recognized proc