On Tue, 19 Sep 2006, Troy Dawson wrote: > Howdy, > I'm getting our first batch of scientific programs into S.L. 4.4. > Right now, I'm just getting in the ones that were in the contrib area. > R and numpy <snip> > I couldn't get atlas to install, or any programs that depend on it, so it's > looking like it won't make it in this release. ATLAS is a strange beast in that building it for a given cpu type is easy enough on that cpu (it will generally auto-detect everything it needs), but I've yet to manage to convince it to build for any different cpu (e.g. build for pentium-III on a P4 etc). Actually differences between versions of CPUs (e.g. cache-sizes etc) mean that one can't be sure that the tuning isn't slightly different for different versions of the P4 anyway. Apparently the Debian dpkg for ATLAS does the magic but their patch looked hideously complex... Since the whole point of ATLAS is that it is supposed to be 'tuned' to the cpu there isn't *much* point in building it in a generic way except perhaps to fill dependencies. I'd be tempted to just make a srpm which builds/tunes itself for the platform it gets installed on but atlas takes so long to build (at least on older machines!) that this would be a major pain. Since ATLAS is really only providing replacement/faster BLAS code anything wanting/depending on ATLAS should really only need any BLAS (though using a faster one is clearly better). Maybe the standard BLAS libraries should end up as links to whatever *best* BLAS is available (if that is possible). If you have a lot of identical machines (e.g. a cluster or similar) then building ATLAS for those is easy enough... Last time I rebuilt ATLAS I ended up with 5 different sets of libraries though at least some of those (e.g. Pentium-II) may not be something I'll worry about next time :-) -- Jon Peatfield, Computer Officer, DAMTP, University of Cambridge Mail: [log in to unmask] Web: http://www.damtp.cam.ac.uk/