Hide Forgot
Currently armadillo BuildRequires blas-devel and lapack-devel and armadillo-devel requires them. It should not be done, since ATLAS already contains all of the necessary functionality; pulling in the reference BLAS and LAPACK packages may actually cause the reference implementation to be used and thus cause execution slower by an order of magnitude. On Fedora 14 I get $ ldd /usr/lib64/libarmadillo.so linux-vdso.so.1 => (0x00007fff349ff000) libblas.so.3 => /usr/lib64/libblas.so.3 (0x00007f6996bd3000) liblapack.so.3 => /usr/lib64/atlas/liblapack.so.3 (0x00007f69963a4000) libcblas.so.3 => /usr/lib64/atlas/libcblas.so.3 (0x00007f6996184000) libclapack.so.3 => /usr/lib64/atlas/libclapack.so.3 (0x00007f6995f6c000) libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f6995c64000) libm.so.6 => /lib64/libm.so.6 (0x00007f69959df000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f69957ca000) libc.so.6 => /lib64/libc.so.6 (0x00007f699542d000) libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f6995148000) libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x00007f6994f2b000) libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x00007f6994743000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6994527000) /lib64/ld-linux-x86-64.so.2 (0x000000329ae00000) libarmadillo should not link against reference BLAS.
You do mention in the documentation that ATLAS is supported but reference LAPACK is needed for some functions that have not been implemented in ATLAS. Then the bug is different - libarmadillo is only linked against ATLAS' version of lapack and not the reference version...
You also might consider updating the Fedora packages to the newest stable versions.
This will have to be a 2 stage update process. I'm currently finishing off the 1.2.0 release of Armadillo, which will be the next stable release pushed to both EPEL and Fedora. I'm not keen on doing any major changes to that release, as "it works as is". In the second stage I'll take a look as to whether the Atlas provided versions of Blas and Lapack are in fact fully ABI compatible with standard Blas and Lapack. If they are, there should be no changes to Armadillo itself, but only to the CMake-based install scripts (eg. the scripts would place preference on the Atlas version of Blas). Note that Armadillo directly calls Atlas functions for critical functionality such as matrix multiplication. As such, even if Armadillo is linked with Blas, it will prefer to use Atlas for such functions. Under RHEL 6 (based on Fedora 12 & 13), the configuration of the Atlas package seems to cause a library override trick, in order to change the run-time linking behaviour of Blas and Lapack. Specifically, if a program requests the standard Blas library, it will actually be linked at run-time with the Atlas provided version of Blas. I don't know whether this behaviour is still in Fedora 14+, as I have a RHEL 6 based machine (for stability reasons).
OK, thanks for the clarification. At least with the manual install one can link directly to the wanted BLAS and LAPACK, is this also possible with the "precompiled" version?
I currently can't update the package -- see Bug 697714 https://bugzilla.redhat.com/show_bug.cgi?id=697714
Closing this bug as I don't have the time to look into this further. Armadillo 2.2.3 is in Rawhide and has been submitted as an update to F16 and EPEL 6.