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

[Baptiste Auguie]

On 12 February 2018 at 04:52, Dirk Eddelbuettel <edd at debian.org> wrote:

>
> On 11 February 2018 at 19:13, Baptiste Auguie wrote:
> | 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
>
> I don't think that is a fair statement.
>
> Armadillo, and RcppArmadillo, offer you an elegant, easy-to-use and rather
> performant interface to underlying LAPACK code.  In the R universe, we rely
> on the LAPACK "brought to us by R". That generally works but ...
>
> ... you are, and have been, pushing the edge further by requiring complex
> data types---and now Conrad chose to rely on another LAPACK routine. Bang.
>
>

As far as I can tell Armadillo added specialised methods for banded
matrices; the routines used to solve non-banded matrices probably haven't
changed.

Coming back to the error itself, what puzzles me is that it seems to be
precisely the OSes relying on external Lapack that have a problem. It
compiles fine on Windows,
https://builder.r-hub.io/status/isolve_1.0.tar.gz-e3da3c1b83
26e62e4e14a913e5bbb5a4

So it seems the problem is distinct from the previous issues with missing
Lapack routines.



> | test for this to help future-proof this recurring issue, but resolving
> the
> | underlying issue is beyond me.
>
> That's the problem.
>
> You may need to look at other package with, when needed, extend offered
> libraries.  I.e. I also stand behind BH and hence parts of Boost, but
> sometimes packages (e.g. in the stan world) need extra functions and so
> they
> package them.  Upstream MLPACK is another example, and it extends Armadillo
> where needed.
>
> Dirk
>
> | 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-757573eaf5
> b0cb30d8154d7b8f7e2bc7
> |
> | 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
> | >
>
> --
> http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>

	[[alternative HTML version deleted]]