[SciPy-dev] scipy.test() failures

[David Cournapeau]

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  
> fblas.so
> ./lib/blas/fblas.so
> ./linalg/fblas.so
>   

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 / 
> usr/local/lib/libblas.a
>       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.

cheers,

David