[R-pkg-devel] Lapack: undefined symbol: zgbsv_
baptiste.auguie at gmail.com
Wed Feb 14 05:12:34 CET 2018
On 13 February 2018 at 22:07, Ralf Stubner <ralf.stubner at r-institute.com>
> 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
> > 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.
> > 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
> 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
> * I do not understand why Mac OS is not affected. The FAQ  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.
> > Or, be brutal, and set '#define ARMA_CRIPPLED_LAPACK 1' everywhere.
> > lines 67 to 95 of RcppArmadillo's configure.ac <http://configure.ac
> > https://github.com/RcppCore/RcppArmadillo/blob/master/confi
> > 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.
> 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
[[alternative HTML version deleted]]
More information about the R-package-devel