[SciPy-dev] scipy.test() failures

[Neil Killeen]

David

On 27/10/2009, at 1:33 PM, David Cournapeau wrote:

> On Tue, Oct 27, 2009 at 11:04 AM, Neil Killeen <nkilleen@unimelb.edu.au 
> > wrote:
>>
>> I'm a bit confused by all the various packagings (bear in mind I am
>> just installing this for end users, I'm not a consumer myself).
>> By going to netlib, which I thought was the home of BLAS,
>> I *did* install from source.
>> ATLAS seems to be repackaging/reimpl of LAPACK and BLAS ?
>> Installing ATLAS seemed rather a lot of bother so I was trying
>> the easy path,
>
> You should not bother with atlas at first - I am sure building it for
> Itanium will be a pain.
>
> There are several things to check for with your build against the
> version from NETLIB website:
> - to check which libraries are actually linked, look at the output of
> ldd on scipy/lapack/fblas.so

First, there appear to be 2 blas shareble objects in the build.

nkilleen@ /usr/local/lib/python2.4/site-packages/scipy> find . -name  
fblas.so
./lib/blas/fblas.so
./linalg/fblas.so

and


1) nkilleen@/usr/local/lib/python2.4/site-packages/scipy> ldd linalg/ 
fblas.so
	linux-gate.so.1 =>  (0xa000000000000000)
	liblapack.so.3 => /usr/lib/liblapack.so.3 (0x20000008000d4000)
	libblas.so.3 => /usr/lib/libblas.so.3 (0x2000000800908000)
	libgfortran.so.1 => /usr/lib/libgfortran.so.1 (0x20000008009bc000)
	libm.so.6.1 => /lib/libm.so.6.1 (0x2000000800aec000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2000000800bbc000)
	libunwind.so.7 => /lib/libunwind.so.7 (0x2000000800bdc000)
	libc.so.6.1 => /lib/libc.so.6.1 (0x2000000800c28000)
	/lib/ld-linux-ia64.so.2 (0x2000000800000000)

2)nkilleen@/usr/local/lib/python2.4/site-packages/scipy> ldd lib/blas/ 
fblas.so
	linux-gate.so.1 =>  (0xa000000000000000)
	libgfortran.so.1 => /usr/lib/libgfortran.so.1 (0x20000008000fc000)
	libm.so.6.1 => /lib/libm.so.6.1 (0x200000080022c000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x20000008002fc000)
	libunwind.so.7 => /lib/libunwind.so.7 (0x200000080031c000)
	libc.so.6.1 => /lib/libc.so.6.1 (0x2000000800368000)
	/lib/ld-linux-ia64.so.2 (0x2000000800000000)


So you can see one of them points to the native blas  in /usr/lib and  
one
doesn't point anywhere.

Now I only built  /usr/local/lib/libblas.a

which the install script seemed to find (see first post which shows log)




> - to check for symbols, the output of nm is very useful as well. In
> particular, depending on the fortran compiler, option and
> architecture, the actual name of the function may be different, this
> is important to know as well: is it srotgm, _srotgm_, _srotgm, etc...


The two fblas.so in the scipy install tree show


nkilleen@/usr/local/lib/python2.4/site-packages/scipy/lib/blas> nm  
fblas.so  | grep rotm
000000000007f418 d doc_f2py_rout_fblas_drotm
000000000007e898 d doc_f2py_rout_fblas_drotmg
000000000007f1e8 d doc_f2py_rout_fblas_srotm
000000000007e7c8 d doc_f2py_rout_fblas_srotmg
000000000004a300 T drotm_
00000000000495f0 T drotmg_
0000000000018c50 t f2py_rout_fblas_drotm
0000000000028460 t f2py_rout_fblas_drotmg
0000000000019870 t f2py_rout_fblas_srotm
000000000002e5e0 t f2py_rout_fblas_srotmg
0000000000053720 T srotm_
0000000000052b90 T srotmg_


and

nkilleen@/usr/local/lib/python2.4/site-packages/scipy/linalg>  nm  
fblas.so  | grep rotm
00000000000592f8 d doc_f2py_rout_fblas_drotm
0000000000058778 d doc_f2py_rout_fblas_drotmg
00000000000590c8 d doc_f2py_rout_fblas_srotm
00000000000586a8 d doc_f2py_rout_fblas_srotmg
                  U drotm_
                  U drotmg_
0000000000018410 t f2py_rout_fblas_drotm
0000000000027c80 t f2py_rout_fblas_drotmg
0000000000019030 t f2py_rout_fblas_srotm
000000000002de40 t f2py_rout_fblas_srotmg
                  U srotm_
                  U srotmg_



I assume 'U' means undefined ?


The static library


nkilleen@/usr/local/lib # nm libblas.a  | grep rotm
drotmg.o:
0000000000000000 T drotmg_
drotm.o:
0000000000000000 T drotm_
srotmg.o:
0000000000000000 T srotmg_
srotm.o:
0000000000000000 T srotm_


> Comparing the name from your custom built libblas.a against the name
> in scipy/lapack/fblas.so should hint at the problem as well.

so all this suggests that the build or run-time environment is not   
correctly
picking up the static blas library and is still using the /usr/ 
lib  .so despite
what the build log says.


>
> David

Questions:

1) why are there two fblas.so objects ?
2) what is the correct way to  get scipy and numpy to pick up  the / 
usr/local/lib/libblas.a
      in both the build and at run-time.   The scipy docs don't  
comment on this...

thanks again
Neil


> _______________________________________________
> Scipy-dev mailing list
> Scipy-dev@scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev