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

[Baptiste Auguie]

Hi,

Sorry I never found the time to put this issue to rest. My cda package has
now been removed from CRAN because Armadillo's update on 'banded
matrices' broke
it on various platforms, and I've had users enquire about the situation. As
far as I can tell RcppArmadillo no longer enables the solution of complex
linear systems on all platforms (see below). I'm happy to contribute a new
test for this to help future-proof this recurring issue, but resolving the
underlying issue is beyond me.

For the sake of clarity and concreteness I've put a minimal example package
here:

https://github.com/baptiste/isolve

which builds on my local mac but fails the online r-hub build
(interestingly, on a linux machine, which also puzzled me about cda's logs)

https://builder.r-hub.io/status/isolve_1.0.tar.gz-757573eaf5b0cb30d8154d7b8f7e2bc7

Thanks for any advice,

baptiste






On 20 December 2017 at 02:24, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> 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
> |
> | PKG_CXXFLAGS=-DARMA_CRIPPLED_LAPACK
> | -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?
>
> Dirk
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>

	[[alternative HTML version deleted]]