[Rd] R 1.7.0 installation problem: make check fails when using --with-lapack option

Kurt Hornik hornik at ci.tuwien.ac.at
Sat Apr 19 21:38:04 MEST 2003

>>>>> Dirk Eddelbuettel writes:

> ...

>> >    Interfaces supported:      X11, gnome, tcltk
>> >    External libraries:        readline, BLAS(ATLAS), LAPACK(generic)

> That mixes Atlas blas with normal lapack. Probably ok, but not a
> combination we tried explicitly.

That's what one currently gets on a Debian (testing at least) system
with some atlas2 -dev package when configuring with --with-lapack.

I am not sure whether it is a real problem, though: LAPACK_LIBS ends up
as -llapack and the lapack.so module has

  liblapack.so.2 => /usr/lib/atlas/liblapack.so.2 (0x40013000)

(assuming atlas2-base-dev installed), which comes from linking againt
-llapack with hard-wiring library paths, and the /etc/ld.so.conf patch
for Atlas ensures that at run time the atlas version is used.

Of course, at configure time we end up finding only the generic -llapack
in /usr/lib.  I assume that it would be more desirable to use -llapack
in /usr/lib/atlas or even /usr/lib/$arch/atlas which come with the
atlas2 -dev packages, but I am not sure how configure could 'easily'
find these.

I see that there is a -llapack_atlas in /usr/lib, but that does not
contain zgeev() and hence cannot be used as a LAPACK replacement.

I am also not sure about the -lblas in /usr/lib/atlas versus the BLAS
libs we currently come up with.

In any case, the current situation is clearly suboptimal because e.g. if
atlas2-base-dev is installed but lapack-dev is not, then no external
LAPACK will be found although there is one ...

If I may suggest something: it would be nice if the atlas2 -dev packages
could come with a /usr/bin/atlas2-config script which could return the
right BLAS_LIBS and LAPACK_LIBS to use with Atlas.


More information about the R-devel mailing list