[R-pkg-devel] Lapack: undefined symbol: zgbsv_

Dirk Eddelbuettel edd at debian.org
Tue Dec 19 14:24:29 CET 2017

On 19 December 2017 at 13:41, Ralf Stubner wrote:
| On 19.12.2017 09:38, Baptiste Auguie wrote:
| > Thanks for the pointer to `arma::solve_opts::no_band`, it sounds like a
| > good solution (assuming the compiler will then skip all the parts
| > related to banded inversion routines). I've been unable to test it so
| > far; I haven't managed to reproduce the error reported on CRAN on a mac.
| Reproducing this error is not easy. I was able to do so using docker

Just work on Windows, or on any R built so that its internal BLAS are
used. You can force that via configure at build time.

| with
| https://github.com/rocker-org/rocker-versioned/blob/master/r-ver/3.4.3/Dockerfile
| as starting point. If you remove lines 30 and 97 (openblas-dev and
| --with-blas), you can build a docker image with R included that uses the
| BLAS and LAPACK supplied by R.
| I have given this a try and installing 'cda' in such a image does indeed
| reproduce the error. Unfortunately adding 'arma::solve_opts::no_band' to
| the two places where arma::solve is used did not help in my tests :-(


Maybe Arma needs another patch.
| > The 'crippled Lapack' macro was useful as a workaround in the past but
| > I'm not sure of its exact mode of operation so I'm reluctant to set
| > something to "cripple" the code (does it target only those routines that
| > are found missing, or is it more of a blanket switch with no fine-tuning?).
| I think it is a blanket switch that will affect also those methods that
| where already added in the past. So this would be only a temporary
| solution, but I think that's what you need right now.
| BTW, setting ARMA_CRIPPLED_LAPACK is more difficult than I thought since
| it is #undefed in the RcppArmadillo-Config. Short of editing that file,
| you can add this to src/Makevars
| -DRcppArmadillo__RcppArmadilloConfigGenerated__h
| I hope there is a better way ...

Set the #define after the #include <RcppArmadillo.h> ?

RcppArmadillo is just the man in the middle.  This is between Baptiste
relying on something that is now always available, and Conrad assuming it is.

I think Baptiste will need to decompose all these pieces and rearrange then.
Or just build his own solve() method based on older Armadillo code?


http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org

More information about the R-package-devel mailing list