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.
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
