[SciPy-user] installation on Suse8.1 (blas problem)
baecker at physik.tu-dresden.de
baecker at physik.tu-dresden.de
Mon Mar 17 13:32:04 EST 2003
Hi Pearu,
[...]
> > What I just did is the following:
> >
> > export BLAS_SRC=/home/baecker/INSTALL_PYTHON/blas
> > in setup_linalg.py:
> > blas_info = {} # test building BLAS from sources.
> >
> > Compilation seems to work, but I did not figure out,
> > where the resulting blas is and how this is linked
>
> setup_linalg.py will build libblas_src.a into build/temp.linux-i686-2.2
> directory and link the fblas extension module with -lblas_src.
> If after export BLAS_SRC=/home/baecker/INSTALL_PYTHON/blas
>
> python scipy_core/scipy_distutils/system_info.py
>
> shows that BLAS sources were found and `blas_info = {}` is set as
> above, the fblas extension module fblas.so (a copy can be found in
> build/lib.linux-i686-2.2/scipy/linalg) should use just built blas
> routines. To be absolutely sure, see the fblas.so linking command
> (there should be no -lblas) and also `ldd fblas.so` might be informative.
I did a total clean up and build scipy again.
Using a python setup.py install | tee install.log
I found the following line involving fblas.so
g77 -shared build/temp.linux-i686-2.2/fortranobject.o
build/temp.linux-i686-2.2/fblasmodule.o -L/usr/lib
-Lbuild/temp.linux-i686-2.2 -Lbuild/temp.linux-i686-2.2 -lfblas -llapack
-lblas_src -lg2c -o build/lib.linux-i686-2.2/scipy/linalg/fblas.so
That looks alright, or ?
However,
`ldd build/lib.linux-i686-2.2/scipy/linalg/fblas.so`
gives
liblapack.so.3 => /usr/lib/liblapack.so.3 (0x400ac000)
libg2c.so.0 => /usr/lib/libg2c.so.0 (0x40607000)
libm.so.6 => /lib/libm.so.6 (0x40626000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40649000)
libc.so.6 => /lib/libc.so.6 (0x40651000)
libblas.so.3 => /usr/lib/libblas.so.3 (0x40770000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
This seems puzzling at first, but in the linker command
above, the linking to -llapack seems not necessary
(i.e. omitting this, the command still works).
But then
`ldd build/lib.linux-i686-2.2/scipy/linalg/fblas.so`
gives
libg2c.so.0 => /usr/lib/libg2c.so.0 (0x4005a000)
libm.so.6 => /lib/libm.so.6 (0x40079000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4009c000)
libc.so.6 => /lib/libc.so.6 (0x400a4000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
I copied the resulting fblas.so to the destination directory.
scipy.test() then gives me a different error, namely
======================================================================
ERROR: check_random (test_decomp.test_qr)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/tests/test
_decomp.py", line 295, in check_random
q,r = qr(a)
File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/decomp.py"
, line 359, in qr
gemm, = get_blas_funcs(('gemm',),(qr,))
File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/blas.py",
line 43, in get_blas_funcs
if ordering and
fblas.has_column_major_storage(arrays[ordering[0][1]]):
File
"/home/baecker/PYTHON/lib/python2.2/site-packages/scipy_distutils/misc_ut
il.py", line 44, in __getattr__
raise self._info[0],self._info[1]
ImportError:
/home/baecker/PYTHON/lib/python2.2/site-packages/scipy/linalg/fblas
.so: undefined symbol: wcdotu_
The same occurs for: check_random_complex, check_simple,
check_simple_complex
However, at the end it says:
----------------------------------------------------------------------
Ran 640 tests in 6.861s
FAILED (errors=4)
<unittest.TextTestRunner instance at 0x868f04c>
So, does this really mean, that the other problem is gone ?
The above wcdotu_ errors could be related to Numeric23.0 ?
Hope you can make more sense out of all this -
Arnd
More information about the SciPy-User
mailing list