[SciPy-user] Can't find atlas for scipy install

Tue Oct 15 11:29:09 EDT 2002

On Tue, Oct 15, 2002 at 02:16:17AM +0300, Pearu Peterson wrote:
> CVS scipy should now detect Debian atlas libraries so that creating the
> symbolic link above would be unnecessary. Can you confirm that?

Ok. I have checked out the last version of scipy in CVS, deleted the
symbolic link (I mean, /usr/lib/3dnow/liblapack.a ->
/usr/lib/3dnow/atlas/liblapack.a), and here are my results:

- Output of scipy_distutils/system_info.py:

atlas_info:
  FOUND:
    include_dirs = ['/usr/include']
    library_dirs = ['/usr/lib/3dnow/atlas', '/usr/lib/3dnow']
    libraries = ['lapack', 'f77blas', 'cblas', 'atlas']

lapack_info:
  FOUND:
    libraries = ['lapack']
    library_dirs = ['/usr/lib']

which seems to be good...

- After compiling and installing it, I've made the next checks:

$ ldd /usr/local/lib/python2.2/site-packages/scipy/linalg/clapack.so
        liblapack.so.2 => /usr/lib/3dnow/atlas/liblapack.so.2 (0x40030000)
        libf77blas.so.2 => /usr/lib/3dnow/libf77blas.so.2 (0x4055d000)
        libcblas.so.2 => /usr/lib/3dnow/libcblas.so.2 (0x40575000)
        libatlas.so.2 => /usr/lib/3dnow/libatlas.so.2 (0x40597000)
        libm.so.6 => /lib/libm.so.6 (0x408ff000)
        libc.so.6 => /lib/libc.so.6 (0x40920000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

$ ldd /usr/local/lib/python2.2/site-packages/scipy/linalg/cblas.so   
        liblapack.so.2 => /usr/lib/3dnow/atlas/liblapack.so.2 (0x40020000)
        libf77blas.so.2 => /usr/lib/3dnow/libf77blas.so.2 (0x4054d000)
        libcblas.so.2 => /usr/lib/3dnow/libcblas.so.2 (0x40565000)
        libatlas.so.2 => /usr/lib/3dnow/libatlas.so.2 (0x40587000)
        libm.so.6 => /lib/libm.so.6 (0x408ef000)
        libc.so.6 => /lib/libc.so.6 (0x40910000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

which seems to be fine

- The first import worked:

Python 2.2.1 (#1, Apr 21 2002, 08:38:44)
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import scipy
>>> scipy.__cvs_version__.cvs_version
(1, 144, 1520, 4355)

so far so good

- when doing the tests:

>>> scipy.test(10)

it I'm getting the next (non-fatal) errors:

the first:

 creating test suite for: scipy.common
    !! FAILURE building test for  scipy.common
        <string>:1: SyntaxError: invalid syntax (test_common.py, line 77)
(in ?)
No test suite found for  scipy.scipy_tempfile

the second:

****************************************************************
WARNING: Importing clapack failed with the following exception:
-----------
exceptions.ImportError:
/usr/local/lib/python2.2/site-packages/scipy/linalg/clapack.so:
undefined symbol: clapack_sgetri
-----------
See scipy/INSTALL.txt for troubleshooting.
Notes:
* If atlas library is not found by scipy/system_info.py,
  then scipy skips building clapack and uses flapack instead.
****************************************************************

the third and last:

 creating test suite for: scipy.linalg.matfuncs
   !! FAILURE building test for  scipy.linalg.matfuncs
      <string>:1: ImportError: No module named test_matfuncs (in ?)
      creating test suite for: scipy.linalg.basic

I've run the tests four times, and these errors are always present. Normally
all the tests ended OK:

.
----------------------------------------------------------------------
Ran 423 tests in 118.583s

OK
<unittest.TextTestRunner instance at 0x866d57c>

but I had this once:

.
======================================================================
FAIL: check_normal (test_morestats.test_anderson)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/usr/local/lib/python2.2/site-packages/scipy/stats/tests/test_morestats.
py", line 46, in check_normal
    assert(scipy.all(A < crit[-2:]))
AssertionError

----------------------------------------------------------------------
Ran 423 tests in 117.422s

FAILED (failures=1)
<unittest.TextTestRunner instance at 0x867306c>

it appeared on my second try, but I was unable to reproduce it. I suppose
this is not important.

Sorry, I don't remember if these errors appeared on the previous version
I've tested.

> 
> Also, the rules of detecting ATLAS libraries are now more flexible: only
> the files libf77blas.a, libcblas.a, libatlas.a must be in the same
> directory. liblapack.a can be either in the same directory, or in the
> subdirectory atlas*, or in a completely different place, or also missing
> but then LAPACK sources must be available.

Great!, that should facilitate the ATLAS inclusion in scipy.

> 
> Btw, does Redhat and other linux distributions provide atlas
> libraries that are optimized for certain CPUs (e.g. Debian provides
> sse, sse2, 3dnow optimized atlas libraries)? If yes, what is the
> location and the names of such libraries? 
> While I am on it, I could add system_info support also for these cases
> now.

I personally have only experience with Debian in the last years...

Cheers,

-- 
Francesc Alted                            PGP KeyID:      0x61C8C11F
Scientific Aplications developer
Public PGP key available: http://www.openlc.org/falted_at_openlc.asc
Key fingerprint = 1518 38FE 3A3D 8BE8 24A0  3E5B 1328 32CC 61C8 C11F