[Numpy-discussion] Debian: numpy not building _dotblas.so

[Robert Kern]

On Tue, Jul 8, 2008 at 14:47, Ondrej Certik <ondrej at certik.cz> wrote:
> On Tue, Jul 8, 2008 at 9:15 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Tue, Jul 8, 2008 at 08:06, Ondrej Certik <ondrej at certik.cz> wrote:
>>> On Tue, Jul 8, 2008 at 11:48 AM, Tiziano Zito <opossumnano at gmail.com> wrote:
>>>> Hi numpy-devs, I was the one reporting the original bug about missing ATLAS
>>>> support in the debian lenny python-numpy package. AFAICT the source
>>>> python-numpy package in etch (numpy version 1.0.1) does not require
>>>> atlas to build
>>>> _dotblas.c, only lapack is needed. If you install the resulting binary
>>>> package on a
>>>> system where ATLAS is present, ATLAS libraries are used instead of plain lapack.
>>>> So basically it was already working before the check for ATLAS was
>>>> introduced into
>>>> the numpy building system. Why should ATLAS now be required?
>>>>
>>>>> It's not as trivial as just reverting that changeset, though.
>>>> why is that? I mean, it was *working* before...
>>>
>>> So just removing the two lines from numpy seems to fix the problem in
>>> Debian. So far all tests seem to run both on i386 and amd64, both with
>>> and without atlas packages installed. And it is indeed faster with the
>>> altas packages instaled, yet it doesn't need them to build. I think
>>> that's what we want, no?
>>
>> Can you give me more details?
>
> Sure. :)
>
>> Was the binary built on a machine with
>> an absent ATLAS?
>
> Yes, the binary is always built on a machine with an absent atlas, as
> the package is build-conflicting with atlas.
>
>> Show me the output of ldd on _dotblas.so with both
>> ATLAS installed and not. Can you import numpy.core._dotblas explicitly
>> under both?
>
> ATLAS installed:
>
> ondra at fuji:~/debian$ ldd /usr/lib/python2.5/site-packages/numpy/core/_dotblas.so
>        linux-gate.so.1 =>  (0xb7fba000)
>        libblas.so.3gf => /usr/lib/atlas/libblas.so.3gf (0xb7c19000)
>        libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb7b67000)
>        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7b40000)
>        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7b33000)
>        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb79d8000)
>        /lib/ld-linux.so.2 (0xb7fbb000)
> ondra at fuji:~/debian$ python
> Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
> [GCC 4.3.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy.core._dotblas
>>>>
>
>
> ATLAS not installed:
>
> ondra at fuji:~/debian$ ldd /usr/lib/python2.5/site-packages/numpy/core/_dotblas.so
>        linux-gate.so.1 =>  (0xb7f2f000)
>        libblas.so.3gf => /usr/lib/libblas.so.3gf (0xb7e82000)
>        libgfortran.so.3 => /usr/lib/libgfortran.so.3 (0xb7dd0000)
>        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7da9000)
>        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7d9c000)
>        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7c41000)
>        /lib/ld-linux.so.2 (0xb7f30000)
> ondra at fuji:~/debian$ python
> Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
> [GCC 4.3.1] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy.core._dotblas
>>>>

Okay, it turns out that libblas on Ubuntu (and I'm guessing Debian)
includes the CBLAS interface.

  $ nm /usr/lib/libblas.a | grep "T cblas_"
  00000000 T cblas_caxpy
  00000000 T cblas_ccopy
  ...

This is specific to Debian and its derivatives. Not all libblas's have
this. So I stand by my statement that just reverting the change is not
acceptable. We need a real check for the CBLAS interface. In the
meantime, the Debian package maintainer can patch the file to remove
that check during the build for Debian systems.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
 -- Umberto Eco