can't use ATLAS or ACML | 2.9.0
Brian - Cheers - followups below.
Prof Brian Ripley wrote:
On Fri, 26 Jun 2009, Evan Cooch wrote:
So, tried again from scratch. Again, CentOS 5.3, which is essentially RHEL 5.3. ./configure --with-blas="-L/opt/acml4.3.0/gfortran64/lib -lacml" In config.log, get things like configure:37199: checking for dgemm_ in -L/opt/acml4.3.0/gfortran64/lib -lacml configure:37230: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/opt/acml4.3.0/gfortran64/lib -lacml -$ conftest.c: In function 'main': conftest.c:189: warning: implicit declaration of function 'dgemm_' /usr/bin/ld: warning: libgfortran.so.3, needed by /opt/acml4.3.0/gfortran64/lib/libacml.so, not found (try using -rpath or -rpath-link)
So you don't have a compatible libgfortran installed (not surprising as your OS is rather old): try a version of ACML of comparable age to your OS that uses. (I seem to remember needed ACML 4.1.0 on Fedora 8.)
Thanks - but I'm not sure I would classify CentOS as 'old' - it is RHEL 5.3 (basically built straight from open-sourced RHEL code), and RHEL 5.3 is the current release of the 'flagship' OS from Redhat. I grant you it *is* old by (say) Fedora standards, which has a release schedule measured in months (whereas RHEL is measured in 1-2 years), but I was aiming for stability.
We also needed to add /opt/acml4.3.0/gfortran64/lib to the ldconfig files (something AMD should organize).
Try ./configure --with-blas="-L/usr/lib64/atlas -lf77blas -latlas" I get the following configure:37199: checking for dgemm_ in -L/usr/lib64/atlas -lf77blas -latlas configure:37230: gcc -std=gnu99 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib64 conftest.c -L/usr/lib64/atlas -lf77blas -latlas -lg$ conftest.c: In function 'main': conftest.c:189: warning: implicit declaration of function 'dgemm_' /usr/bin/ld: cannot find -lf77blas collect2: ld returned 1 exit status configure:37236: $? = 1 configure: failed program was: What puzzles me is that lf77blas is definitely in /usr/lib64/atlas - but configure couldn't find (?). Perhaps its because 100% of the libs in the atlast subdir are xxx.so.3 (perhaps R config is looking for so.1 libs?).
It is looking for .so or .a (a Linux linker always does). Where did you get ATLAS from? This is what happens if you install the foo and not the foo-devel RPM for some package. And indeed, on Fedora 10 you need the atlas-devel RPM ....
Ah - that rings a bell (can you tell I was doing this late into the wee hours?). Atlas was distributed as an RPM (or, rather, downloaded via the CentOS standard yum repo). Everything in /usr/lib64/atlas is an .so.3 file - nothing with .so or .a as suffix.
I suspect that many/most of the problems I'm having with getting R to compile (with BLAS and LAPACK) are related to these basic issues - if I can't do even a simple compile with blas, then whats left?
Ask for local help on your OS! You seem to be asking many questions about your OS here, and be assured that R works with ATLAS and ACML flawlessly in well-sorted OS installations. Things like the need for the foo-devel RPM are in the R installation manual which the INSTALL file asked you to study (before posting).
Well, I've actually gone through the manual you refer to - missed the bit on foo-devel (which applies only to atlas, it would seem) - my oversight - mea culpa. However, the documentation doesn't (and isn't expected) to elaborate on what you refer to as a 'well-sorted' OS. In other words, I had no a priori expectation of a problem - since CneenOS is RHEL, and RHEL has a rather large market share. I would have assumed (naively, in hindsight) that the combination of CentOS and ACML 4.3.x would have been 'well sorted'. (as an aside - some of my friends at Sun tell me 'standard Linux' for file structures, libs and such is an oxymoron ;-) It would appear not - at least in this instance. On the other hand, CentOS picked up all of my twitchy harddare (RAID cards, special NICs) without missing a beat, networked without so much as a single tweak being needed, and has performed flawlessly for everything...except getting R compiled with ACML support.
Note that a much simpler way (as recommended the manual!) to add an optimized BLAS is to switch the libRblas. E.g. I have a note in my build file gannet% cat I.USED ## later ## mv lib/libRblas.so lib/libRblas.so.keep ## ln -s /opt/acml4.3.0/gfortran64_mp/lib/libacml_mp.so lib/libRblas.so And most users of R do so little linear algebra that an optimized BLAS make a negligible difference in performance (but often an appreciable one to accuracy).
Agreed on the latter point (generally), but I do a fair bit of stuff with big matrices, and wanted both accuracy *and* speed. Wrt to the first point, I tried that in fact (but didn't report - in fact, I tried about 15-20 different combinations of various approaches). When I try that - using *exactly* that syntax (above), and do the compile, I got the following error message when starting R: /usr/local/lib64/R/bin/exec/R: error while loading shared libraries: libacml_mv.so: cannot open shared object file: No such file or directory So, try LD_LIBRARY_PATH=/opt/acml4.3.0/gfortran64/lib export LD_LIBRARY_PATH Seems to do the trick, but I think I'm botching tweaking R_HOME/etc/ldpaths to set this permanently. Is there a doc somewhere on how to tweak ldpaths? Sorry if I've missed it... Again, thanks for wading through my various missives. If R wasn't mission critical to my users (and R with 'better blas') wasn't critical to *me*, I wouldn't be so fussed about it.