From: Jason Riedy
Date: Thu, 14 Aug 2008 15:20:57 -0400
And Ondrej Certik writes:
Jason, then you are in the best position to help us with the package.
Not really; no time. Luckily, LAPACK just produces libraries for
now. The other portions (e.g. making the test programs more
useful for remote diagnostics) require far more LAPACK work than
anyone can give at the moment. Contributions welcome.
My personal builds make the package once for static libraries,
then once for dynamic. The .a files are squirreled away after
each build, and the .a build with -fPIC is picked apart (ar x)
and recombined (gfortran -shared). Easy enough that I've never
even scripted it.
BTW, do you know anyone who could help us with the atlas package? It
also needs fixing and a new upstream version should be packaged.
I looked into that at one point and ran away screaming. Added
Clint to the cc list explicitly. IIRC, the two things that would
make packaging ATLAS much easier:
1. An easy method to compile using some moderate defaults with *no
tuning*. Package auto-builders should not tune.
2. A long-term method for storing and using saved tuning
values. Long-term meaning that new ATLAS releases can
relevant read old values.
The first would help distributions (and sites with no spare admin
time) install one baseline package across all their systems.
Perhaps it could be addressed by packaging the GEMM-based BLAS
with a moderately optimized GEMM rather than ATLAS. I suspect
that almost all copies of ATLAS in use are *not* tuned for the
The second eases distribution of a source-based autotuning
package. Upgrades still would build a tuned BLAS (and LAPACK?)
but tune only what has changed. The tuning values would be
treated as any system-specific configuration files.
These likely are possible now, but the amount of work it takes
for an outsider to figure out how seems about as much as
rewriting the build system.