[Rd] can't use ATLAS or ACML | 2.9.0

[egc]

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.