We saw a crash in many computers, in the octave check phase, where octave crashed.
It was due to atlas being built for AMD Family 10h, which has a special SSE
trick that others computer don't have.
For x86_64, atlas is for K7. And for i686, PII.
svn path=/nixpkgs/trunk/; revision=33780
build machine because that feature offsets the performance timings. We ignore
that check, however, because with binaries being pre-built on Hydra those
timings aren't accurate for the local machine in the first place. The build log
might show something such as the following:
| It appears you have cpu throttling enabled, which makes timings
| unreliable and an ATLAS install nonsensical. Aborting.
| See ATLAS/INSTALL.txt for further information
| Ignoring CPU throttling by user override!
svn path=/nixpkgs/trunk/; revision=32506
Linking octave with clapack did not work.
I updated lapack, and additionally I build it with atlas, instead of blas. That should give
better performance. I don't know if atlas builds everywhere though.
On the other hand, maybe some programs linking with liblapack will fail. We'll have to check
the hydra reports.
I plan to remove clapack; liblapack provides a C interface too.
svn path=/nixpkgs/trunk/; revision=32464
It's not entirely clear whether BLAS is in the public domain, but according to
<87636orixx.fsf@gnu.org> Debian did classify it that way, and the license text
sure feels like the authors intend the package to be in the public domain. So
here we are.
svn path=/nixpkgs/trunk/; revision=19686
