[Python-modules-team] Bug#448530: bug reproduced

Ondrej Certik ondrej at certik.cz
Thu Dec 20 19:01:01 UTC 2007


On Dec 20, 2007 5:36 PM, Ondrej Certik <ondrej at certik.cz> wrote:
> > I have forwarded this bug upstream:
> >
> > http://projects.scipy.org/pipermail/numpy-discussion/2007-December/030320.html
> >
> > Do you think you could take part in the discussion in there to help
> > trace this bug down?
>
>
> Hi Jan,
>
> upstream is willing to help with fixing this bug, but unfortunately, I
> don't really have much time
> in digging into this - if you have time, could you please provide some
> information to them,
> like a gdb backtrace?
>
> Just send it to the mailinglist above.


Paul Metcalfe has sent me this explanation:

I think it's a packaging problem with linear algebra.

pdm at ratatosk:~$ dpkg --status python-numpy
Package: python-numpy
Status: install ok installed
Priority: optional
Section: python
Installed-Size: 5400
Maintainer: Debian Python Modules Team
<python-modules-team at lists.alioth.debian.org>
Architecture: i386
Version: 1:1.0.4-3

[snip]

ratatosk:/usr/lib/python-support/python-numpy/python2.4/numpy# ldd
core/_dotblas.so
       linux-gate.so.1 =>  (0xffffe000)
       libf77blas.so.3 => /usr/lib/sse2/libf77blas.so.3 (0xb7a0a000)
       libcblas.so.3 => /usr/lib/sse2/libcblas.so.3 (0xb74f9000)
       libatlas.so.3 => /usr/lib/sse2/libatlas.so.3 (0xb6f4f000)
       libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb6f37000)
       libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6dea000)
       libg2c.so.0 => /usr/lib/libg2c.so.0 (0xb6dc2000)
       libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb6d9d000)
       /lib/ld-linux.so.2 (0x80000000)

i.e. linking directly against the atlas libraries rather than via
liblapack and libblas.

lapack_lite is even better:

pdm at ratatosk:/usr/lib/python-support/python-numpy/python2.4/numpy/linalg$
ldd lapack_lite.so
       linux-gate.so.1 =>  (0xffffe000)
       liblapack.so.3 => /usr/lib/atlas/sse2/liblapack.so.3 (0xb78ef000)
       libf77blas.so.3 => /usr/lib/sse2/libf77blas.so.3 (0xb73e1000)
       libcblas.so.3 => /usr/lib/sse2/libcblas.so.3 (0xb6ecf000)
       libatlas.so.3 => /usr/lib/sse2/libatlas.so.3 (0xb6926000)
       libg2c.so.0 => /usr/lib/libg2c.so.0 (0xb68fe000)
       libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb68d9000)
       libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb68ce000)
       libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb6781000)
       libblas.so.3 => /usr/lib/atlas/sse2/libblas.so.3 (0xb61a2000)
       /lib/ld-linux.so.2 (0x80000000)

[note linkage against liblapack, libf77blas, libcblas and libblas.]

Issue 1: debian prefers you to link against liblapack & libblas if at
all possible.

Issue 2: debian liblapack & libblas do not provide ATLAS (and in
general they can't, since libblas could just be the Fortran reference
blas), which _dotblas wants (numpy/core/setup.py)

Issue 3.  I will file an RC bug report just as soon as debian ships
python-numpy without an optimized _dotblas.so ... ;-)

Actually, _dotblas just wants cblas, so it is something of a bug in
numpy that it insists on Real Genuine ATLAS to build _dotblas.

What I don't understand is how the .deb package managed to find ATLAS
so that it could build _dotblas.so at all ?

I'd also have a look at the compiler options... numpy is capable of
building with -msse2 if it's built on a recent enough box with a
recent enough compiler.  Which I guess debian doesn't approve of ?

[What to do about all this is the real question, and I don't have an answer.]

But it's late in the day, and I've just got in from work, so all this
could be crazed ramblings...

Ondrej

P.S. CCing to Kumar, as he has some knowledge in this.





More information about the Python-modules-team mailing list