Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_
On 12 February 2018 at 04:52, Dirk Eddelbuettel 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 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 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 re
Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_
On 12 February 2018 at 22:16, Baptiste Auguie wrote: | 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. Maybe we are setting a more global "no advanced lapack" for Windows that assures success when we assume that the other system will always have it. One thing you could try is to write a configure test in your package so that at build time a compile+link for the particular symbol is made. If the test succeeeds, export a new HAVE_XYZ_BANDED_ROUTINE define and then convince Conrad to respect that flag. Otherwise have the code fall back to alternatives just like the Windows build. Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere. See lines 67 to 95 of RcppArmadillo's configure.ac: https://github.com/RcppCore/RcppArmadillo/blob/master/configure.ac#L67-L95 I could generalize the use in inst/include/RcppArmadilloConfigGenerated.h.in by respecting prior definitions, ie wrapping #ifndef around them. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] CMake on win-builder
Dear all, I am trying to create a R interface to a C++ library which itself uses cmake as its build tool. For experimenting the idea, I copy the entire source of the library to a sub-directory of "inst" and call "cmake" in the "configure" script, then call "make", which generates a static library. In another package, I write C code that interfacing with R and provide the PKG_LIBS variable with the path of the static library. This approach works on my machine (openSUSE), I would like to try to port it to windows in future. Since this package needs cmake at build time, is it possible to add cmake to the win-builder? And I have found two previous discussions about cmake: 1. https://stat.ethz.ch/pipermail/r-package-devel/2015q2/97.html 2. https://stat.ethz.ch/pipermail/r-package-devel/2016q2/000897.html Also, I am in fact relative new to the build tools, do you have any suggestions or comments on the approach taken? The two packages are: 1. https://github.com/marlin-na/Rlibsymengine (ship the C++ library) 2. https://github.com/marlin-na/symengine.R Any help would be appreciated. Thanks! Jialin __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Lapack: undefined symbol: zgbsv_
On 13 February 2018 at 01:05, Dirk Eddelbuettel wrote: > > On 12 February 2018 at 22:16, Baptiste Auguie wrote: > | 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. > > Maybe we are setting a more global "no advanced lapack" for Windows that > assures success when we assume that the other system will always have it. > it sounds plausible, but it would be nice to know for sure. In particular, it doesn't explain why the external Lapack on linux appears to be missing these symbols (they're not very recent, as far as I can tell). I don't really know how to figure this out, but it seems to be key. > One thing you could try is to write a configure test in your package so > that > at build time a compile+link for the particular symbol is made. > I have no idea how to do this, and if did... > If the test succeeeds, export a new HAVE_XYZ_BANDED_ROUTINE define and then > convince Conrad to respect that flag. Otherwise have the code fall back to > alternatives just like the Windows build. > ... IIRC Conrad made it clear in the past that he would not consider further special cases for crippled Lapacks. > Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere. See > lines 67 to 95 of RcppArmadillo's configure.ac: > https://github.com/RcppCore/RcppArmadillo/blob/master/configure.ac#L67-L95 > while this might solve the CRAN problem, it doesn't feel right to enforce the use of suboptimal routines throughout and on all platforms, including those that do in fact provide a full-fledged external Lapack. > I could generalize the use in inst/include/RcppArmadilloConf > igGenerated.h.in > by respecting prior definitions, ie wrapping #ifndef around them. > > Dirk > > -- > http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org > b. [[alternative HTML version deleted]] __ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
