[Rd] looks in liblapack.a not liblapack.so

[Peter Dalgaard]

Prof Brian Ripley <ripley at stats.ox.ac.uk> writes:

> Which confirms the wisdom of our advice not to use --with-lapack
> unless you have to (a few systems do).  (Quote from the R-admin manual
> 
>  	this is definitely *not* recommended
> 
> . Perhaps this needs to say `use at your own risk and do not report
> problems with it'!)
> 
> There are far too many rogue LAPACK builds out there in distros.

Right, and I did of course know about the warning and the reason for
it. I just thought that when yet another distro saw fit to put a
liblapack out, the least we could do was to test it...
 
> BTW, I don't understand how a Linux distro can supply ATLAS tuned to
> my CPU/FPU.  Dr Goto has had about ten versions of his optimized BLAS
> covering just a small subset of i686 CPUs.  So although a distro's
> ATLAS may be better than a generic BLAS, it seems that it is likely to
> be suboptimal, and perhaps disastrous (I've seen that with mobile
> Pentium chips using ATLAS tuned on desktop machines).  So the
> recommendation must remain to tune ATLAS on your specific hardware.

I don't think an RPM is restricted to contain only one version of the
binaries, so in principle, the post-installer could adapt the
installed version to your hardware, if it could narrow the choice down
to a dozen versions or so. It's not easy though, since not only the
CPU/FPU types factor in, but also cache sizes and memory speeds.

-- 
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark          Ph:  (+45) 35327918
~~~~~~~~~~ - (p.dalgaard at biostat.ku.dk)                  FAX: (+45) 35327907