On Tue, Jul 8, 2008 at 10:19 PM, Robert Kern <[EMAIL PROTECTED]> wrote: > On Tue, Jul 8, 2008 at 14:47, Ondrej Certik <[EMAIL PROTECTED]> wrote: >> On Tue, Jul 8, 2008 at 9:15 PM, Robert Kern <[EMAIL PROTECTED]> wrote: >>> On Tue, Jul 8, 2008 at 08:06, Ondrej Certik <[EMAIL PROTECTED]> wrote: >>>> On Tue, Jul 8, 2008 at 11:48 AM, Tiziano Zito <[EMAIL PROTECTED]> 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: >> >> [EMAIL PROTECTED]:~/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) >> [EMAIL PROTECTED]:~/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: >> >> [EMAIL PROTECTED]:~/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) >> [EMAIL PROTECTED]:~/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 _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
