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

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

-- 
Matthias Burger

Bioinformatics R&D
Epigenomics AG                      www.epigenomics.com
Kleine Pr?sidentenstra?e 1          fax:   +49-30-24345-555
10178 Berlin Germany                phone: +49-30-24345-0

On Thu, Apr 17, 2003 at 08:34:45PM +0200, Matthias Burger
wrote:
> compiling R 1.7.0 with gcc 3.1.1 on Debain Linux (woody stable) with the 
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).
> configure option --with-lapack works but make check fails in test base-R 
> with the message
[...]

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.

[...]
> Is this a known problem with gcc 3.1.1? Or my configure call configuration?
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

-- 
Don't drink and derive. Alcohol and algebra don't mix.

Matthias Burger <ml-it-r-devel@epigenomics.com> writes:
> 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
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.

Hi,

just as a follow up:

as suggested by my sys admin I make use of the environment variable LD_PRELOAD 
to tell the run time linker where to find the desired libraries.

export 
LD_PRELOAD=/usr/lib/sse2/atlas/libblas.so.2:/usr/lib/sse2/atlas/liblapack.so.2

   echo $LD_PRELOAD
/usr/lib/sse2/atlas/libblas.so.2:/usr/lib/sse2/atlas/liblapack.so.2

   > system("ldd R.bin")
         /usr/lib/sse2/atlas/libblas.so.2 => /usr/lib/sse2/atlas/libblas.so.2
(0x40016000)
         /usr/lib/sse2/atlas/liblapack.so.2 => 
/usr/lib/sse2/atlas/liblapack.so.2 (0x403ec000)
         libg2c.so.0 =>
/usr/lib/gcc-lib/i386-linux/3.2.2/../../../libg2c.so.0
(0x40919000)
         libm.so.6 => /lib/libm.so.6 (0x40946000)

[...]
so this works now as expected.

But testing with the example provided by Ram?n D?az-Uriarte
I can confirm that I get the errors as well,
filed as bug report PR# 2823 already.

So for the time being I conlude that I will not enable ATLAS support.

I'b be very happy to hear of any news or development on resolving this
problem.

Regards,

   Matthias



-- 
Matthias Burger

Bioinformatics R&D
Epigenomics AG                      www.epigenomics.com
Kleine Pr?sidentenstra?e 1          fax:   +49-30-24345-555
10178 Berlin Germany                phone: +49-30-24345-0