[Python-modules-team] Bug#464784: python-numpy: After transition to gfortran _dotblas.so is lost

Kumar Appaiah akumar at ee.iitm.ac.in
Sun Feb 24 10:16:25 UTC 2008


Dear tiziano,

On Sat, Feb 23, 2008 at 11:28:22AM -0800, otizonaizit at yahoo.com wrote:
> and the following code snippet was added to the file:
>  if ('NO_ATLAS_INFO',1) in blas_info.get('define_macros',[]):
>                 return None # dotblas needs ATLAS, Fortran compiled blas will not be sufficient.
> 
> which clearly indicates that dotblas is now, for some reason which I really
>  don't know, dependent on ATLAS. To get dotblas built in, it is enough to
>  remove the debian patch:  02_dontuse_lapack.diff . I tested it and the
>  resulting python-numpy packages contain _dotblas.so correctly linked to
>  the optimized atlas library.
> 
> This of course would mean Depends: libatlas3-headers, libatlas3gf-base |
>  libatlas3gf-sse2 | etc...
> I would think that the bug actually is not a bug but a wishlist item and
> that it has nothing to do with the gfortran transition.
> Would you add dependency to atlas and give numpy a manyfold speed
>  improvement?  

I agree that not using Atlas is going to result in a huge performance
penalty. However, the trouble is that Atlas has not really completed
the gfortran transition, and has not yet built on all architectures
yet:

http://buildd.debian.org/~jeroen/status/package.php?p=atlas

In case we start Build-depending on Atlas now, this would mean that we
will not be able to get numpy built on these architectures.

Also, numpy seems to be special, in that it seems to be very sensitive
to being built against Atlas. Other packages seem to want only
Blas/Lapack and happily use the Atlas system when it is installed,
without a rebuild.

Thanks for reporting this, but for now, I can just say you might have
to rebuild with Atlas. A better suggestion to overcome this problem is
welcome though.

Thanks!

Kumar
-- 
Kumar Appaiah,
458, Jamuna Hostel,
Indian Institute of Technology Madras,
Chennai - 600 036
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/python-modules-team/attachments/20080224/23b9750d/attachment.pgp 


More information about the Python-modules-team mailing list