[R-pkg-devel] Lapack: undefined symbol: zgbsv_
On 13 February 2018 at 22:07, Ralf Stubner <ralf.stubner at r-institute.com> wrote:
On 13.02.2018 05:49, Baptiste Auguie wrote:
On 13 February 2018 at 01:05, Dirk Eddelbuettel <edd at debian.org
<mailto:edd at debian.org>> wrote:
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.
It is the case, c.f. https://github.com/RcppCore/RcppArmadillo/blob/master/inst/i nclude/RcppArmadilloConfig.h#L96-L106
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. My understanding: * On Windows internal LAPACK is used but it is not affected due to the defines quoted above. * At least Debian & Co but probably also other Linux distributions compile R with external LAPACK and are not affected. * CRAN (and probably r-hub) use R compiled with internal LAPACK and is therefore affected.
Thanks Ralf, now it makes more sense to me. I had misunderstood the situation on CRAN and r-hub and thought they used an external Lapack on linux.
* I do not understand why Mac OS is not affected. The FAQ [1] implies that by default the internal BLAS/LAPACK is used. But then I do not see the mentioned alternative libRblas.vecLib.dylib on a test system. [1] https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which -BLAS-is-used-and-how-can-it-be-changed_003f
Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere.
See
lines 67 to 95 of RcppArmadillo's configure.ac <http://configure.ac : https://github.com/RcppCore/RcppArmadillo/blob/master/confi
gure.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.
You could use this as a first step to get the package back into CRAN. Later on you can try to only set the flag when an internal LAPACK is detected, similar to the way RcppArmadillo does it. If my understanding above is correct, the number of users with ARMA_CRIPPLED_LAPACK in your package but not in RcppArmadillo will be quite small.
It would make sense to test for internal vs external Lapack and decide based on that (regardless of the OS); as you say, the results should be essentially identical to what happens when the same user installs RcppArmadillo on their machine. Unfortunately I don't know how to proceed. I copied RcppArmadillo's configure.ac script and tried to extract just the Lapack testing bits, but these macro and configure concepts are totally foreign to me. I believe it would be helpful to have a minimal example of this type of configuration for the dummy isolve package ( https://github.com/baptiste/isolve), if someone with such expertise and a linux machine is willing to help. Thanks, baptiste
Greetings Ralf -- Ralf Stubner Senior Software Engineer / Trainer R Institute GmbH Dortustra?e 48 14467 Potsdam T: +49 331 23 70 81 66 F: +49 331 23 70 81 67 M: +49 162 20 91 196 Mail: ralf.stubner at r-institute.com Sitz: Potsdam Register: AG Potsdam HRB 27966 P Ust.-IdNr.: DE300072622 Gesch?ftsf?hrer: Prof. Dr. Dr. Karl-Kuno Kunze