[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.
Best
-k
More information about the R-devel
mailing list