[Rd] ATLAS threaded 64 bit Opteron build for R: need -fPIC

Amit Aronovitch aronovitch at gmail.com
Fri Feb 10 16:53:47 CET 2006

Prof Brian Ripley wrote:

> On Fri, 10 Feb 2006, Amit Aronovitch wrote:
> You set the reply address to Martin Maechler!  That's antisocial.
Sincere apologies. I certainly didn't intend to!
(I probably misclicked while trying to put him on Cc: )

   Please ignore that header.

>> Hi,
>> Sorry for sending such a late reply, and for being abit OT.
>>  I've been trying to compile 64 bit ATLAS for numpy
>> (http://numeric.scipy.org/ ), and so far this thread is the most
>> useful one I could google up - thanks!.
>>  I encountered similiar problems, and so far could not get a .a
>> linkable to numpy (comparing to your post - it seems I might have
>> forgotten to add the -fPIC for the F77FLAGS or MMFLAGS).
> Yes, that _is_ in the R-admin manual.  I guess you have not read that
> - it describes how to install R.  You can get it in the R tarball from
> ftp://ftp.stat.math.ethz.ch/Software/R/R-devel.tar.bz2
>> Also, I'm having trouble with the ATLAS lapack. To get a usable lib,
>> one has to merge it with a full lapack implementation (as described
>> in the ATLAS errata). However, I'm using RHEL4, and their installed
>> liblapack.a seems to have been compiled without -fPIC, so the merged
>> library is unlinkable to numpy's .so. Is there a way to use Redhat's
>> installed liblapack.so?
> No, nor should you want to.  If RHEL4 is like FC3/4 watch out, as RH
> have managed to get BLAS routines in liblapack and not liblas, and use
> incorrect patches to LAPACK 3.0.  (Again, see the latest R-admin manual.)

Thanks for the tip - guess that means I'll have to compile my own lapack...

>> Few questions about your compiler flags:
>> 1) Is there a reason to compile with -O rather than -O3?
>> (did you try and encounter some problem, or found no major performance
>> difference)
> ATLAS chose that.  Since the real work is done by hand-tuned assembler
> code it should not matter.
>> 2) I see you use -mfpmath=387 - does this work better than sse2 (which
>> seems to be
>> the default)? How about the "sse,387" option - should I try that?
> Depends on your ATLAS version.  Again, ATLAS chose those.
> As it happens, I have been trying to build ATLAS on my new dual
> Opteron box this morning.  The latest devel version (3.7.11) does not
> build, as at some point it says it expects the GNU x86-32 assembler. 
> If it did it would use SSE3 and so be faster.
> Both 3.6.0 and 3.7.11 fail because my machine is too fast, and I had
> to increase the number of replications (1000) in make/Make.{mv,r1}tune
> and in tune/blas/level1/*.c.  Even then I do not entirely trust the
> results (and the two versions report different L1 caches sizes ...).
> I got pretty exasperated with this (it needed about ten builds to get
> one that succeeded).  Both ACML and the Goto BLAS work well out of the
> box on Opterons, but do have licence issues. (Again, see the R-admin
> manual for details.)
I'll certainly have to read the R-admin manual.
Once I manage to get a working lib I'll try posting some of that info to
ATLAS lists (should prbly be included in atlas errata or something).

  thanks alot,
      Amit A.

More information about the R-devel mailing list