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

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.

| 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