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

Ondrej Certik ondrej at certik.cz
Tue Jul 8 16:47:57 EDT 2008


On Tue, Jul 8, 2008 at 10:19 PM, Robert Kern <robert.kern at gmail.com> wrote:
> 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

Right.

> meantime, the Debian package maintainer can patch the file to remove
> that check during the build for Debian systems.

Yes, I just did that. Thanks for the clarification.

Ondrej



More information about the NumPy-Discussion mailing list