[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