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