[SciPy-dev] scipy.test() failures
Mon Oct 26 22:09:58 CDT 2009
Neil Killeen wrote:
> First, there appear to be 2 blas shareble objects in the build.
> nkilleen@ /usr/local/lib/python2.4/site-packages/scipy> find . -name
Yes, there are two fblas libraries - the lib one is redundant (it was
started as an effort to put blas/lapack into its own package so that
linalg would use those, but this was never finished AFAIK).
> 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_
It looks like one was linked against the static library whereas the
other one was linked against the shared version. That's odd.
> I assume 'U' means undefined ?
Yes it does - it would be resolved once liblapack.so is loaded.
> 1) why are there two fblas.so objects ?
> 2) what is the correct way to get scipy and numpy to pick up the /
> in both the build and at run-time. The scipy docs don't
> comment on this...
That's not easy to do. By far, the simplest is to put the static
libraries in a directory where there is no shared version, and to edit
site.cfg so that those directories are looked for at first.
Don't trust too much what the build output says, except for the actual
command executed. The scipy build output is messy, and a lot of
information are not accurate or just plain wrong.
More information about the Scipy-dev