On 13.02.2018 05:49, Baptiste Auguie wrote:
> On 13 February 2018 at 01:05, Dirk Eddelbuettel <e...@debian.org
> <mailto:e...@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.
> 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.
* 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
* 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. See
> lines 67 to 95 of RcppArmadillo's configure.ac <http://configure.ac>:
> 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.
Senior Software Engineer / Trainer
R Institute GmbH
T: +49 331 23 70 81 66
F: +49 331 23 70 81 67
M: +49 162 20 91 196
Register: AG Potsdam HRB 27966 P
Geschäftsführer: Prof. Dr. Dr. Karl-Kuno Kunze
Remail@example.com mailing list