Skip to content

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

6 messages · Douglas Bates, Dirk Eddelbuettel, Kurt Hornik +1 more

Original
Matthias Burger
# 
Greetings,

compiling R 1.7.0 with gcc 3.1.1 on Debain Linux (woody stable) with the 
configure option --with-lapack works but make check fails in test base-R with 
the message

[...]
 > kappa(x1 <- cbind(1,1:10))# 15.71
[1] 15.70590
 > kappa(x1, exact = TRUE)        # 13.68
[1] 13.67903
 > kappa(x2 <- cbind(x1,2:11))# high! [x2 is singular!]
[1] 8.351867e+16
 >
 > hilbert <- function(n) { i <- 1:n; 1 / outer(i - 1, i, "+") }
 > sv9 <- svd(h9 <- hilbert(9))$ d
 > kappa(h9)# pretty high!
[1] 728289149562
 > kappa(h9, exact = TRUE) == max(sv9) / min(sv9)
Error in La.svd(x, nu, nv, method) : LAPACK routine DGEBRD gave error code -10
Execution halted

As I understand from the configure output (and config.status) R used the 
-L/R_HOME/bin -lRlapack
but this seemed to have built ok.

compiling anew after configure with the same option set but without 
--with-lapack make check yields not error test base-R

Is this a known problem with gcc 3.1.1? Or my configure call configuration?
There are lapack dyn libs installed for my system so I thought configure would 
find those - did I make a mistake in the configure options?

Any hints would be very wellcome.


Just now, for testing reconfigured (after make clean) and recompiled with gcc 
2.95.4 using the --with-lapack option and failed make check again (same error). 
So what could be wrong with the lapack option?


Regards,

    Matthias



details:

export CC=gcc-3.1 CXX=g++-3.1

   ./configure --prefix=/mnt/local/R/R-1.7.0-gcc-3.1.1 --enable-R-profiling=yes 
--enable-R-shlib=yes --with-f77 --with-blas=yes --with-lapack=yes 
--with-readline=yes --with-tcltk=/usr/include/tcl8.3 
--with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh 
--with-tk-config=/usr/lib/tk8.3/tkConfig.sh --enable-shared --with-pic --with-x 
--with-gnome --with-gnome-includes=/usr/include/gnome-1.0 
--with-recommended-packages --with-aqua=yes  --with-libpng=yes 
--with-jpeglib=yes --with-zlib=yes --with-bzlib=yes --with-pcre=yes 
--with-libglade-config=/usr/bin/libglade-config

   configure output:

   R is now configured for i686-pc-linux-gnu

   Source directory:          .
   Installation directory:    /mnt/local/R/R-1.7.0-gcc-3.1.1

   C compiler:                gcc-3.1 -D__NO_MATH_INLINES -mieee-fp -g -O2
   C++ compiler:              g++-3.1 -mieee-fp -g -O2
   Fortran compiler:          g77 -mieee-fp -g -O2

   Interfaces supported:      X11, gnome, tcltk
   External libraries:        readline, BLAS(ATLAS), LAPACK(generic)
   Additional capabilities:   PNG, JPEG, bzip2, PCRE
   Options enabled:           shared library, R profiling

   Recommended packages:      no
Dirk Eddelbuettel
#
On Thu, Apr 17, 2003 at 08:34:45PM +0200, Matthias Burger wrote:
As announced last night, R 1.7.0 packages are already available for Debian
unstable (as usual via Debian mirrors) as well as Debian testing and stable
(via CRAN).
[...]

We did not see that. I would suggest that you grab either the procompiled 
packages from CRAN, or their sources if you want to rebuild locally. The
latter option is appealing as you get both the package management
intgegration and a build off your locally installed libs.

[...]
Possibly. I update my Debian machines (mostly testing) almost daily, and I
never had a gcc 3.1.1 -- but testing now has a choice of 2.95, 3.0, 3.2 and
3.3 all of which can be installed at the same time.  You may have your
reasons to stick with gcc 3.1.1, but you then need to accept that we cannot
solve your issues for you as we work from a different set of released and
supported software.

Hth, Dirk
Douglas Bates
# 
Matthias Burger <ml-it-r-devel@epigenomics.com> writes:
Very peculiar.  I just checked the machine where I compiled the
R-1.7.0 Debian packages for the stable distribution.  During the
Debian package build we do run 'make check' and that succeeded on that
machine.

Now I get the peculiar situation that, with h9 the 9x9 Hilbert matrix,
I can successfully run

svd(h9)
svd(h9, nu = 0)
svd(h9, nv = 0)

but

svd(h9, nu = 0, nv = 0)

fails with the error that you quote.

I compiled these packages with g77-3.0 for the Fortran compiler.  Are
there known problems with that?

On another machine running Debian testing and using the gcc-3.2
compiler suite the tests pass.
Dirk Eddelbuettel
#
On Thu, Apr 17, 2003 at 02:07:19PM -0500, Douglas Bates wrote:
This looks like you're mixing 3.1 for gcc/g++ and the default (2.95 ?) for
g77. Probably risky.
That mixes Atlas blas with normal lapack. Probably ok, but not a combination
we tried explicitly.
Uggh. My apologies for replying too soon earlier.

Dirk

  
    

      
      
    

  


  


      

    

    
2 days later

    

      
      

        


  

        

      Kurt Hornik
    

    

      
      #
    

  


  

          

      
      
      
    

        
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

  
  


  


      

    

    
2 days later

    

      
      

        


  

        

      Matthias Burger
    

    

      
      #
    

  


  

      
Hi again,

first I'd like to thank you for the prompt replies and insights.

So here is my next attempt log:
After some conversation with my local sys admins I convinced them to install gcc 
3.2.2 (also g++ and g77 for that version) compiled for Debain woody stable (!) 
as that is our site wide system setup.

And yes I simply had forgotten to set the correct g77 version (thanks to Dirk 
for pointing this out).

As we have now one central installation point for R (and not on each host 
individually) I cannot use the Debian package system I believe. Even if so I do 
not have root access and thus have to stick to comile myself from src.

So after some experimenting my host now is configured with packages
blas  &  blas-dev (Version: 1.1-9)
lapack2 & lapack2-dev (Version: 3.0.20000531a-18)
and
atlas2-sse2 & atlas2-sse2-dev (Version: 3.2.1ln-7)

exporting the gcc variables, make distclean

configure (see below)

make
runs through but
make check
fails with the same error in base.R as reported earlier.

ldd bin/R.bin reports

kuhn burger 243 (R/R-1.7.0-inst): ldd bin/R.bin
         libblas.so.2 => /usr/lib/sse2/atlas/libblas.so.2 (0x40027000
         libg2c.so.0 => /usr/lib/libg2c.so.0 (0x403fd000)
         libm.so.6 => /lib/libm.so.6 (0x40419000)
         libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4043b000)
         libpcre.so.3 => /usr/lib/libpcre.so.3 (0x40443000)
         libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x4044c000)
         libz.so.1 => /usr/lib/libz.so.1 (0x4045c000)
         libreadline.so.4 => /lib/libreadline.so.4 (0x4046c000)
         libdl.so.2 => /lib/libdl.so.2 (0x40492000)
         libncurses.so.5 => /lib/libncurses.so.5 (0x40496000)
         libc.so.6 => /lib/libc.so.6 (0x404d4000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

  so it seems to find the libblas
but starting R and doing the same I get

 >system("ldd bin/R.bin")
         libblas.so.2 => /usr/lib/gcc-lib/i386-linux/3.2.2/../../../libblas.so.2 
(0x40016000)
         libg2c.so.0 => /usr/lib/gcc-lib/i386-linux/3.2.2/../../../libg2c.so.0 
(0x40079000)
         libm.so.6 => /lib/libm.so.6 (0x400a6000)
[...]

even if I set
export LD_LIBRARY_PATH=/usr/lib/sse2/atlas:$LD_LIBRARY_PATH
I get the same picture.

Now I have no further knowledge how to check & persuade the run time linker to 
pick up the correct libs. In any case I believ this to be the cause of the 
failure or am I grossly mistaken?

Any suggestions what I could try next (or just leave it and  waive lapack support) ?


Regards,

   Matthias



details:

kuhn burger 249 (R/R-1.7.0-inst): /usr/bin/gcc-3.2 --version
gcc-3.2 (GCC) 3.2.2
Copyright (C) 2002 Free Software Foundation, Inc.


    ./configure --prefix=/mnt/local/R/R-1.7.0-gcc-3.2.2-atlas2-sse2 
--enable-R-profiling=yes --enable-R-shlib=yes --with-f77 --with-blas=yes 
--with-lapack=yes  --with-readline=yes --with-tcltk=/usr/include/tcl8.3 
--with-tcl-config=/usr/lib/tcl8.3/tclConfig.sh 
--with-tk-config=/usr/lib/tk8.3/tkConfig.sh --enable-shared --with-pic --with-x 
--with-gnome --with-gnome-includes=/usr/include/gnome-1.0 
--with-recommended-packages=/mnt/local/R/R-1.7.0-recommended-inst 
--with-aqua=yes  --with-libpng=yes --with-jpeglib=yes --with-zlib=yes 
--with-bzlib=yes --with-pcre=yes --with-libglade-config=/usr/bin/libglade-config



R is now configured for i686-pc-linux-gnu

   Source directory:          .
   Installation directory:    /mnt/local/R/R-1.7.0-gcc-3.2.2-atlas2-sse2

   C compiler:                /usr/bin/gcc-3.2 -D__NO_MATH_INLINES -mieee-fp -g -O2
   C++ compiler:              /usr/bin/g++-3.2 -mieee-fp -g -O2
   Fortran compiler:          /usr/bin/g77-3.2 -mieee-fp -g -O2

   Interfaces supported:      X11, gnome, tcltk
   External libraries:        readline, BLAS(generic), LAPACK(generic)
   Additional capabilities:   PNG, JPEG, bzip2, PCRE
   Options enabled:           shared library, R profiling

   Recommended packages:      no

        
Kurt Hornik wrote:

            

      
      
      
    

        
[...]