[SciPy-dev] adding LAPACK and BLAS to the source code
oliphant.travis at ieee.org
Sun Jun 23 21:05:02 CDT 2002
On Sun, 2002-06-23 at 13:45, eric jones wrote:
> Hey group,
> Apologies if you get this twice -- we had a mail list hiccup earlier
> this week, and I don't think this went out correctly.
> We just had the unpleasant experience of getting SciPy to build on the
> Sun architecture. In the end, it didn't prove that hard -- it was all
> the mis-steps that were painful. Most of SciPy builds without a hitch
> -- it is only the LAPACK and BLAS stuff that causes major problems.
I had thought it would be easier to get optimized LAPACK and BLAS with
> The issue is that many LAPACK's are built with vendor specific compilers
> instead of g77, so getting the correct libraries to link in when
> compiling with distutils is a major headache. And, once the link works,
> the headaches continue with chasing down random seg-faults that appear
> to come from incompatible library ABI issues.
Ah, this is the problem with using those.
> We worked with ATLAS for a while, but finally backed off to working with
> just the standard LAPACK and BLAS.
Why did ATLAS not work?
> The result was a pain free build
> because gcc and g77 were used all the way through. I expect building
> everything with the Sun compilers would also go fairly smoothly using
> this approach. It seems like most of the questions we get on building
> SciPy have to do with ATLAS and linear algebra. On windows and Linux,
> we about have this problem licked. But its still difficult on platforms
> with multiple compilers. So, I am planning to put LAPACK and BLAS into
> the SciPy CVS so that they are built with the same compiler as the rest
> of SciPy and no longer have to be built separately.
Won't this result in slow code on those machines?
> This will increase
> the repository size substantially (LAPACK is big), but has little other
> side effects. We'll set up the building of LAPACK and BLAS so that they
> are optional -- if you have ATLAS or other LAPACK libraries you'd like
> to use, you can specify them in the site.cfg package -- or at least
> specify that system_info should search for them. This search will be
> turned off by default, however, so that incompatible lapack/blas/atlas
> libraries are not found.
It seems like in CVS the default should be to use the optimized LAPACK
given that this is the default most of the developers would want to
use. Is the site.cfg file managed by CVS? If so, then our constant
changes to this file will undoubtedly result in checking in a version
that searches by default.
It would seem that a check for certain machines and a subsequent turning
off of that option would be better.
More information about the Scipy-dev